Tag: architecture

There are architectures and patterns that look cool on paper, and there are ones that are good in practice. Implementing the hexagonal architecture with Camel is both: cool to talk about, and a natural implementation outcome. I love going hexagonal with Camel because it is one of these combinations where the architecture and the tool come together naturally, and many end up doing it without realizing it. Let’s see why that is the case.

Open vSwitch is growing every day and being used in large-scale deployments. Usually, that means there are few ports configured in the vswitch that will be always available, like physical Ethernet ports and several other ports providing networking connectivity to virtual machines or containers. Those other ports are software devices and very often they cannot be reused after a reboot or a system crash for example.

This blog post will talk about how to make sure the vSwitch comes up clean after a system crash or bad shutdown. The idea is that once vSwitch is up, there is no need for another component (usually a remote controller) to iterate over a large number of stale ports and clean them up.

Before I start talking about IT and how you can manage, control, and optimize your Hybrid IT infrastructure, I propose that we reflect directly on your living room, where you usually watch TV, movies, listen to music, play video games, etc. Even if you do not enjoy this type of entertainment, you know that for each of these devices, it is common to use a remote control allowing you to switch between them, manage them, and control all of your favorite programming. While these devices are converging to an all-in-one architecture, they are truly multi-functional. We’ve learned how to handle remote controls at a very young age and it’s the reality we live in. In this case, you are faced with heterogeneous devices and various remote controls, where the number of controls increases as you acquire new devices. It is difficult to have to manage the complexity of a simple task that is to manage your schedule, operating multiple devices, through different controls, with numerous features, and different vendors. Products and vendors bring specific features, use different nomenclature, and provide some features which may or may not be compatible with each other. Going beyond, some of these features made available by vendors, will not even be used throughout the lifetime of these devices, a real waste!

Picture 1 – Managing many devices with many remote controls

Considering this scenario, you might be wondering: What is the relationship of the complexity of having to deal with various entertainment devices and remote controls with your IT infrastructure? And what does this have to do with cloud computing or Hybrid IT?

Continue reading “CloudForms: Manage your IT and Hybrid Cloud through a single platform”

As part of a two-day microservices workshop I’m putting together, I’ve been thinking a lot about how to explain monolith-application decomposition and what a transition to microservices might look like. This is a small subset of that material, but I want to share it with you to get feedback (in the workshop we go into more detail about whether you should even break up your monolith). I base this on my own tried and true real-life experience as well as my work with the many Red Hat customers I’ve met over North America for the last few years. Part I explores the architecture while the second part (to be released shortly) will cover some technology that can greatly help in this area. Follow along (@christianposta) on Twitter or http://developers.redhat.com for the latest updates and discussion.

… with APIs, OpenID, and Microservices, Daria Mayorova and Mark Cheshire from Red Hat 3Scale shared their presentation on how to construct microservice-based applications with the benefits of API management.

So recently, the idea that Monoliths should be discouraged and that Microservices be embraced has taken over the Software Development space. A project made into a single code base is to be taken out and broken into manageable pieces. It is better to work with manageable sub-units than a whole bunch of one big stuff. Well, as the saying goes, small-scale always wins.

As a consultant for Red Hat, I have the privilege of seeing many customers. Some of them are working to find ways to split their applications in smaller chunks to implement the microservices architecture. I’m sure this trend is generalized even outside my own group of the customers.

There is undoubtedly hype around microservices. Some organizations are moving toward microservices because it’s a trend, rather than to achieve a clear and measurable objective.

In the process, these organizations are missing a few key points, and when we all awake from this microservices “hype”, some of these organizations will discover that they now have to take care of ten projects when before they had one, without any tangible gain.

To understand what it takes to reap real benefits from microservices, let’s look at how this neologism came to being.