Not Ready for Microservices? Evolutions and Alternatives

Why did the chicken cross the road? As the old saying goes, to get the other side.

Why did the company move to microservices? That answer isn't nearly as simple.

While the buzz around microservices continues to grow, it can be valuable to look at various paths that companies take to achieve their ultimate goals of delivering software faster and with higher overall quality. This past week, I had a chance to sit down with Red Hat's Director, Developer Experience (Burr Sutter, @burrsutter) to discuss how companies balance Monoliths and Microservices. In that discussion, we looked at the trends around Java frameworks, the role of Continuous Integration (CI) in building better software, as well as how to measure success as your business embarks on this journey.

Starting from Scratch

In some cases, it's not a matter of "moving" to microservices, but rather starting from scratch with a new set of applications.

For many companies, such as startups or large company "Center of Excellence" groups, microservices are the starting point. They allow companies to experiment with new ideas, free from the legacy application baggage that may currently be slowing down their business. Microservices allow teams to begin to understand the new challenges that comes with building

 smaller application services, such as service discovery, independent scaling, distributed monitoring, API versioning, etc. Having the right microservices platform in place is important, especially for developers. Microservices also forces teams to work through the changes needed to understand how (or if) a 2-pizza-team structure would actually work in their specific culture and environment. This approach aligns well with the Pioneer phase of the Pioneers-Settlers-Townplanners framework. Especially for existing companies that are looking to drive internal "DevOps" changes (here, here), it can be critical to demonstrate that something new is possible and showcase this to influential people and groups within the business to get the backing needed to expand these capabilities. It's a strategy that has been documented in books like "Made to Stick" as a way to overcome the inherent inertia that resists change.

Breaking Apart the Monolith

Many companies tend to have a love-hate relationship with their monolithic applications. On one hand, they love the stability that these applications provide to support the mission-critical elements of their business. On the other hand, they are often frustrated at the complexity required to make minor changes or updates. An example of this might be a requirement to add a new set of social-media centric authentication credentials for users (e.g. login using Facebook or Twitter). This aspect of the application may change much more frequently that the core application, so it would make sense to break it apart and use something like Red Hat SSO (based on the "Keycloak" project) as an authentication microservice. This approach is frequently referred to as the "Strangler Pattern", where elements of an existing application are squeezed off from the core application into smaller sub-functions, or microservices. Each of these sub-functions can then be viewed as an independent project for updates, testing and deployment. This approach aligns very well to the concepts within OpenShift of "projects", "pods", and "pipelines". Other examples that we frequently see are companies moving from legacy middleware platforms to Red Hat JBoss EAP or Websphere Liberty, or evolving existing Java applications to use SpringBoot. In all of these scenarios, the native containerization in OpenShift allows the applications to run faster and take advantage of integrated scaling and multi-cloud support.

Making the Monolith Run Faster 

For all the benefits that microservices could provide, they don't come without a new set of challenges. Managing these new challenges might not always be worth the effort or risk. The monolithic application might be "working" perfectly fine, but the systems surrounding the monolith may require some tuning and hygiene. A great example of this is the transformation at Key Bank, moving their release cycles from every three months to every week. By not only taking advantage of the native services and automation within OpenShift, but also improving their testing infrastructure and process, Key Bank was able to improve the most important metric - Responsiveness to the Market.

Monoliths AND Microservices - It's about Business Value

Far too often, engineers get caught up in the mechanics of the systems they are building. They highlight the number of services available in the platform and forget that the ultimate measuring stick is the experiences of the platform users. The platform itself must provide economic value to the business, and the end-users must be able to easily solve their problems (learn, share, engage, buy). In reality, for most companies, the way to deliver this experience will be a combination of microservices AND monolithic applications. The right platform will be able to manage both types of applications, as well as integrate into the tools and workflows that developers need to build and deliver software faster and with higher quality.

Across a broad set of industries, Red Hat OpenShift customers are seeing how the right platform can help them with their microservices and monolith journey. We'd love to hear about how your company is managing their journey, both from a technology and people/process perspective. Let us know your experiences, @openshift.