5 things enterprise architects should know about microservices

Enterprise Architects who want to learn more about microservices and their potential benefits might find it odd to read about rabbit hutches. However, a blog post by Developer Advocate Niklas Heidloff sets the stage for a discussion about why microservices are so compelling, as well as what Architects should keep in mind when evaluating the model for their organizations.

Heidloff last year bought his children two rabbits—supposedly, two females. It turned out that one of the bunnies was a boy, and, well, you can imagine the outcome. The bunny cage quickly became too small for the original two rabbits’ progeny. Heidloff built a set of hutches connected by pathways, but individual pens could also be closed from each other to, for example, separate male rabbits from female rabbits.

In a blog post including lots of adorable photos and a diagram, Heidloff explains how this system of hutches is similar to loosely coupled microservices. “The pathways are like network traffic which can be controlled via Kubernetes and Istio,” he wrote.

Image

Heidloff added that the hutch system analogy demonstrates the reasons why enterprises should modernize applications with microservices and other cloud-focused technology: More agility, better experience, and reduced costs.

The microservice model: Beyond bunnies

Indeed, microservices can be built and deployed independently of one another, improving not only developer productivity and flexibility but also application resiliency. Microservices can be constructed from the ground up, or legacy monolithic applications can be broken down into microservices. In either case, microservices are a key enabler of development in a cloud-native model.

However, microservices have a reputation for complexity. Also, not every monolith is well suited to be transformed into a set of microservices. Enterprise Architects play a crucial role in helping the organization determine when and where microservices make sense and—perhaps more importantly—laying the groundwork for the cultural shift that needs to occur for microservices to be successful.

Here are five things enterprise architects should know about microservices:

1. Microservices hold a lot of promise

According to research by Forrester, an effective microservices implementation has the potential to increase the rate of business innovation and responsiveness by:

• Speeding app delivery
• Enabling quick, incremental app changes
• Ensuring resiliency at scale
• Optimizing production costs
• Supporting graceful editing
• Freeing developers to use the best tools for the job

Indeed, according to research by TechRepublic Premium, companies that have adopted microservices are realizing some of these benefits.

TechRepublic Premium conducted an online survey in the spring of 2020 to gauge awareness about microservices, as well as usage and benefits. Organizations that have integrated microservices noted that they see faster deployment of services (69%). Respondents also reported greater flexibility to respond to changing conditions and the ability to quickly scale up new features into large applications (61% and 56%, respectively).

2. Microservices can introduce or shift complexity

The microservices model makes sense on paper, but not always in practice. Microservices can easily get out of hand—especially if an organization dives into the microservices deep end from the get-go.

“A badly designed microservices approach can lead to ‘microservice sprawl,’” states the Capgemini report Monolith to Microservices, an Integration Journey. Without centralized control and discipline, the report continues, “the number of microservices will grow exponentially and create an IT landscape that is complex, difficult to manage, and actually reduce reuse rather than increase it.”

To avoid this kind of sprawl, microservices planning must include tools and platforms for management, orchestration, and company-wide training.

3. Microservices requires a significant cultural shift

Perhaps the biggest predictor of an organization’s potential for reaping the rewards from microservices is its willingness and ability to make a pretty significant cultural shift.

In the traditional development model, each team involved in developing an application works in a siloed fashion, throwing its work “over the wall” after it’s finished. Microservices are built more cohesively, with cross-functional teams responsible for developing their microservices and the customers of their microservices. This enables organizations to focus development on a business problem and update services as soon as business needs and/or goals dictate. It’s all good, especially from an Enterprise Architect viewpoint. However, if the organization’s departments are siloed and teams are not working collaboratively, it’s not easy to get there.

4. Not every monolith (or everything in a monolith) is made for microservices

In their enthusiasm for microservices, some organizations go all in—picking away at every piece of their monoliths to pull out microservices. However, sometimes it doesn’t make sense to “microservice-ize” certain parts of a monolith—or even to touch the monolith at all. Indeed, when it comes to monoliths, the best course of action often is: If it isn’t “broken,” don’t fix it.

In a great piece on Red Hat Enable Sysadmin, Eric D. Schabell recommends questions to ask when thinking about moving monolithic applications to microservices:

• What is the performance impact of microservices?
• How do we handle state while splitting up our monoliths?
• How do we handle our data with distributed microservices?
• How do we test stateful micro(services)?
• Should we use API management or a service mesh?

In general, organizations should look for discrete functions that will work effectively when coupled with other microservices within an application. Organizations should also make sure they don’t make microservices too big (defeating the purpose of microservices in the first place) or too small (increasing the potential for that “microservice sprawl” mentioned earlier).

5. Microservices require vital enabling technologies and tools

One of the benefits of (and ways of getting people on board for) microservices is that teams can pick the tools and languages they use to develop microservices. However, according to IBM Cloud Learn Hub, several core tools are essential for microservices implementation:

Containers, Docker, and Kubernetes

Containers, a model popularized by Docker, are the compute model most closely associated with microservices, states IBM Cloud Learn Hub. And, just like microservices, containers can quickly proliferate. Kubernetes has become the de-facto standard for managing and orchestrating containers.

API gateways

Microservices can communicate directly with each other, but API gateways are often used as microservices-based applications grow. Organizations can use API management platforms, or if the microservices architecture is being implemented using containers and Kubernetes, a service mesh like Istio can be used, notes IBM Cloud Learn Hub.

Messaging

IBM Cloud Learn Hub notes that it may be best practice to design stateless services, but that state nonetheless exists and services need to be aware of it. State-establishing API calls can be combined with messaging or event streaming to provide more flexibility. Not every service will process messages as quickly as they receive them, so flexibility is critical. This can be accomplished by a general-purpose message broker or an event streaming platform such as Apache Kafka.

Serverless

The serverless model allows developers to build and run applications without having to manage servers. Servers are still part of the equation, of course, but they are abstracted away from the app development process. The unit of execution in serverless is a function, which is commonly understood to be even smaller than a microservice.

Functions run in the public cloud can be spun and scaled up and down as needed, with organizations paying for what they need as they go. The goal of both functions and microservices is to create more efficient deployment units and scale and update on demand. Organizations can use both, depending on the workload, to increase overall efficiency and resiliency.

The bottom line

The value of microservices is clear, but there are lots of blurry lines along the way. With their 360-degree view on the organization, its legacy technology, and the culture that exists among and between different departments, Enterprise Architects are uniquely suited to offer the clarity needed to adopt and apply microservices technology strategically.