For the past few months, I’ve been digging into my new role with a group of Portfolio Architects, looking specifically at integration as the key to omnichannel customer experience.
It’s an interesting challenge in that we’ve been given the mission of creating architectural content based on common customer adoption patterns. That’s very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you’re basing the content on actual execution in solution delivery, you’re cutting out the chuff.
What’s that mean?
It means that it’s going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures, and interactions that actually have been proven to work.
What’s not included is any vendor promises that you’ll find in normal marketing content: those promises that, when it gets down to implementation crunch time, might not fully deliver.
Enter the term architectural blueprint.
In this series of articles, let’s look at these blueprints, how they are created, and what value they provide for your solution designs.
Continue reading “How integration is key to customer experience (Part 1)”
Microservices architecture (MSA) has become very popular.. However, one common problem is how to manage distributed transactions across multiple microservices. This post is going to share my experience from past projects and explain the problem and possible patterns that could solve it.
What is a distributed transaction?
When a microservice architecture decomposes a monolithic system into self-encapsulated services, it can break transactions. This means a local transaction in the monolithic system is now distributed into multiple services that will be called in a sequence.
Continue reading “Patterns for distributed transactions within a microservices architecture”
This post is a short summary of my recent experiences with customers that are implementing architectures similar to microservices but with different characteristics in the current post-microservices world.
The microservices architectural style has been around for close to five years now, and much has been said and written about it. Today, I see teams deciding not to strictly follow certain principles of the “pure” microservices architecture and to break some of the “rules.” Teams are now more informed about the pros and cons of microservices, and they make context-driven decisions respecting team experience and organizational boundaries and accept the fact that not every company is Netflix. Below are some examples I have seen in my recent microservices gigs.
Continue reading “The rise of non-microservices architectures”
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.
Continue reading “Hexagonal Architecture as a Natural fit for Apache Camel”
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.
Continue reading “Open vSwitch without stale ports”
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 (see part II) 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.
Continue reading “Low-risk Monolith to Microservice Evolution Part I”
… 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.
Continue reading “Blueprint for Modern Application Architecture”
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.
Continue reading “7 Things to Worry About w/Microservices”
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.
Continue reading “An Incremental Path to Microservices”