At MuleSoft, we regularly have discussions with organizations about the role of our integration and API platform in the context of a microservice architecture. Some organizations firmly believe that all they need is a team of generic microservices developers. But quite a few “born-in-the-cloud” companies use MuleSoft as their integration and API platform.
We will explore the reasons behind this choice along two axes: organizational and technical considerations. But before going there, let’s revisit the microservice architecture concept.
Microservice strategy architecture
The demands of today’s customers are higher than ever. They want a personalized and connected experience when interacting with any brand, and they expect companies to have an understanding of their needs. Fifty-five percent of organizations that were interviewed for our 2022 Connectivity Benchmark Report are finding it difficult to integrate user experiences.
Organizations need to move fast to keep up, and this is where microservices come in.
In a microservice architecture, you build smaller, targeted services instead of large monolithic applications. These services are faster to build, easier to maintain, and help foster agility.
In an article about article microservices, the authors note:
“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
– James Lewis and Martin Fowler
Anatomy of a microservice
What is it that a microservice does; what is inside this service? A microservice delivers its functionality by executing logic. You can distinguish three types of logic in a microservice:
- Business logic: The actual business functionality
- Integration/orchestration logic: Orchestrating and transforming the output of multiple services
- Connectivity logic: Interacting with backend applications like ERP and CRM
The ratio between these types of logic depends per use case. The image below shows three categories of microservices based on the main role of the service.
For example, in a retail context, a business service could be a component that handles a user’s order process; an integration service could be a component that generates a customer profile (orders, recommendations, personal info) at sign-on; and a connectivity service could be a component that API-enables elements of the backend ERP system.
The question we can ask ourselves is: should we develop all these services in the same way with the same team and the same tools?
Organizational considerations
Let’s take a look at two organizational considerations for implementing a microservices strategy: innovation myopia and choosing the “best person for the job”.
Innovation myopia
Innovating in the technology stack does not equate to innovating the business. Most organizations adopt a microservice strategy to enable agility at scale. These resulting innovative, business driven, projects have a high visibility in the organization and are often well funded.
In more traditional organizations (i.e. not born-in-the-cloud), these initiatives are seen as (and used as) an opportunity to break with the past; “this time we are going to get it right”; “what has gotten us here will not get us where we want to go”.
This can lead to either oversimplification or duplication:
- Oversimplification: All the focus is on the innovation part of the project (mostly business services). The innovation project expects some other part of the organization will be able to deliver the integration and connectivity services. This will result in: lower agility as innovation projects are still constrained by the legacy solutions.
- Duplication: The innovation project treats all services the same, irrespective of the type. All required services are built from scratch using the same technology. Some organizations literally spin up a digital copy of themselves. This will result in additional cost: maintaining two sets of the same services; higher development costs: custom coding non-differentiating services; and inconsistent customer experience across engagement channels.
Best person for the job
Finding and keeping people with the right skills is one of the biggest challenges, also in IT. In the context of a microservices strategy the following questions need to be answered:
- Can we attract enough pure microservices developers?
- Do we want our microservices developers to be able to solely focus on differentiating business services or do we also require them to work on integration and connectivity services?
- Do we think our microservices developers actually want to be bothered with connectivity and integration services?
Some of MuleSoft’s born-in-the-cloud customers have concluded that the answer to all three questions is negative. As a result, they have attracted people with different skill profiles and offer these people different toolsets.
Sometimes the drive toward microservices adoption is about “best job for the person,” also called CV-driven development. The main driver to use container-based technologies was career progression for 40% of survey respondents as it looks good on their CV.
CV-driven development can lead to resume-driven development (RDD). Organizations that want to embark on a microservices journey look for resumes that contain microservices development. The person behind that resume may see microservices as the solution to any problem that is placed in front of them.
Technical considerations
Now, we’ll take a look at a few technical considerations for implementing a microservices strategy: off-the-shelf applications, choosing the “best tool for the job,” and characteristics outside of a traditional ESB.
Off-the-shelf applications
Even the most innovative organizations adopt off the shelf applications for ERP, CRM, HR and other non-differentiating functionality. To run their business, they will need to integrate to those systems.
There are multiple ways to do that in various microservices patterns. No pattern is one-size-fits-all, and each has its own set of benefits and prerequisites. Eventually, data needs to flow in and out of these off the shelf applications. Data from these applications may need to be combined to deliver a 360-degree view of customers, products and employees.
An integration platform may do a better job at connectivity and integration than a generic programming framework.
Best tool for the job
One of the principles of microservices is polyglot programming. Polyglot programming is the practice of writing code in multiple languages to capture additional functionality and efficiency not available in a single language.
The reason why organizations are adopting an integration platform is that these platforms have specific functionality to efficiently design, build, secure and manage integration and connectivity services.
But doesn’t an integration platform conflict with the “smart endpoints, dumb pipes” microservices priciple? Well, that depends on the platform.
In practice, you can see pragmatism gradually trumping purism in microservice architecture; the service mesh architectural pattern was introduced as a generic solution to solve common microservices challenges like security, fault tolerance, and scalability. By introducing service mesh functionality, organizations were no longer forced to custom code governance considerations behind microservices into the service code itself.
Not your parents’ ESB
Some other principles of microservices are that they are loosely coupled, independently scalable and independently deployable using fully automated CI/CD pipelines. These principles do not match the characteristics of the traditional Enterprise Service Bus (ESB).
This is nicely illustrated in Holly Cummins’ blog Seven Ways to Fail at Microservices:
The ESB is part of what Cummins calls The Enterprise Hairball. Because the integration layer is monolithic, they have to carefully schedule all changes, which blocks everybody else.
In MuleSoft’s Anypoint Platform, integration and connectivity microservices can be deployed, scaled and managed separately. There is no concept of a central monolithic ESB; each service is running in its own container. That is why these services fit perfectly in a microservice architecture.
Conclusion
Now it’s all about delivering the best possible experiences to customers, citizens, partners and employees. Organizations need agility to deliver these experiences at scale. The microservices paradigm is the architectural foundation for agility.
To maximize the value of their microservice architecture, modern organizations leverage a broad set of skills and polyglot development to deliver a diverse set of microservices. MuleSoft’s Anypoint Platform is the perfect foundation for creating, deploying and managing integration and connectivity microservices.
