Microservices Are Not Fixing Your Enterprise’s Problems
Microservices are no longer a new paradigm. Instead some enterprises already find themselves disillusioned by them. Other enterprises are just starting their Microservice initiatives.
Microservices are fine-grained services that make it easier to write, deploy and manage components.
The name implies that the most important indicator, if it’s a Microservices or not, is the size, however this may be misleading.
“The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.” .” (Fowler & Lewis)
Some enterprises haven’t started employing Microservices architectures, while others are already disillusioned.
At integrationWorks we love them, they have been instrumental in solving many of our clients problems. They won’t fix your businesses problem, by themselves though. Some issues may even be highlighted by their usage. In this article I’ll be looking at these issues and how to avoid them.
Unclear Requirements
As written earlier, sizing is not the most important factor in judging Microservice-ness. A good measurement is replaceability. This means how well can a service be replaced with a new one. This includes clean well-documented interfaces.
The first step is usually decomposing business functions into services. The danger here is to only map existing backend functions onto new Microservices.
This may check the box in a Powerpoint presentation, but it won’t help with business agility. A single monolith is typically replaced by many microservices. Development, deployment and management may be even harder than before.
To get the maximum benefit from these architectures, it’s important to find the right process decomposition rules.
A good first step in a Microservices project may then be to define the business landscape. A potential model in the banking space is the Banking Industry Architecture Network (BIAN).
To do this part of the decomposition process, the business must have a clear understanding what it wants to solve with Microservices. To change and endpoint is a lot easier than to remap the landscape. The ideal landscape fits the organization though and abstract models like BIAN are just the starting point.The landscape can be understood in terms of
- Applications and Backend Services — What does the Service consume?
- Integrations — What are the data integrations?
- Business Processes — What value does a service provide?
It is tempting to start with the first view, but the biggest business value is usually gained by the last view. A model to help define this view is the Value Proposition Interface Canvas.
To insure the quality of the specifications enterprises should also define acceptance criteria. This is even more important with these architectures, as they are coupled more loosely. A bad specification will take longer to resolve if it is spread among many teams.
Data Model
Microservices put the data model definition on the service level. A global or common data model if may seem like a perfect match for Microservices. By defining a global interchange format, the interface is stable and the services can be developed independently.
The danger is that the format becomes too abstract, once it includes all the use cases in the enterprise. Then data like account and amount have to encompass so many cases that they become basically meaningless. Especially if the common data model becomes part of the REST API. The goal of an API should be, to be easy to understand by humans. Very few holistic data models can full-fill that. The model should be easily understood by the business and may create it’s own business value
As part of the decomposition phase I would also suggest defining your data model building blocks instead. The actual interface definition is then specific to the Microservice itself.
Defining these building blocks seems trivial at first. But enterprises that have decades of legacy software may have a myriad of definitions how to express data. For example booleans may be expressed as “0” and “1”, “true”/”false”, “yes”/”no” and so on. What is a street address, what is an account and how to express an amount. This increases the ramp-up time but it will make it easier to use and write. Developers won’t have to think about how many characters a street name has each time they are using an address. And a company wide address format will for example create a lot of business value by itself, as not every project has to define their own mapping rules.
Transparency
An API catalog can allow consumers to understand the available services. In the world of Microservice architectures this is a common tool to make the available endpoints transparent. This is not an automatic process, though. Effort needs to me made to create clear and concise documentation. The examples provided need to be self explanatory and work out of the box. To reach that goal, the whole Organization needs to be transparent. If using the legacy system requires mystic rituals, than it is difficult to create an transparent API. An Organization needs to understand that a lot of the value of the Microservice layer will be in its transparency and usability. This means either re-architecting the in-transparent systems in the enterprise. Or insure the Microservice is an understandable layer on top of legacy systems instead of mimicking the existing system in REST API’s. Common data models and a good specification help as well.
Organizational Agility
Often the business side supports the Microservice initiatives because they want to increase the speed of change. Startups may be encroaching on the enterprise on all sides and requirements change faster than ever. Decomposing the individual business functions, allows speeding up the development lifecycle. Since functions are less interwined they can be developed, tested and deployed independently. If the enterprise still uses fixed release cycles, a lot of this benefit may be lost. The benefit of Microservices is to drive the deployment by businesss needs instead of technical schedules. Microservices can be deployed much more flexible due to their decoupled nature. The gain from this agility can only be realized if the organization itself is agile enough. This may even include examining the tolerance of an organization, for errors and outages of certain non-essential services. The old adage is still true, even with Microservices. “Quality, speed, price — pick two”. Even with solid tests, there is still a tradeoff between total agility and reliability . Also contrary to Startups, that aim to grow as fast as they can, enterprises have a deep interest in sustainability and lifecycle management. This will limit them in the agility. Licenses, SLA’s and support play a much stronger role.
The business side should be aware of that tradeoff. Most enterprises will find themselves with a release cycle length between Monoliths and total agility.
Skills
Microservices aim to make services easily replaceable, easy to write and to understand. This means that the enterprise can use lower skilled workers and save money. Or so the thinking goes.
In reality Microservices often involve hard problems. For example how to handle transactions along different services. How to parallelize the processes effectively. How to monitor, log and trace across process and server lines.
The microservices concept of a small team that owns the whole service also can lead to a lot of complexity. If the skillset is not sufficient, the microservice mindset might lead to a wonderful mess of copy and paste that is held together by hope and belief.
Instead of enabling lesser skilled people to participate in the enterprise development the opposite may be true.
Higher skilled resources are needed for the microservices. Developers that can effectively communicate, write great code and think about the complete process.
Microservices can enable great people to get even more done.
But it can also end in an uncontrollable mess, if it’s not accompanied by good skills and governance.
Governance
Closely related to the skills is the area of Governance. Microservices are supposed to be built by small teams that are fully independent in deciding the tech stack.
In the enterprise, with support contracts, SLA’s and long-lived software, a wildly heterogeneous tech stack may tough to effectively manage.
A clear decisions should be taken how literal the idea is, that each team can decide the tech stack by themselves. Also the strategy may expose an ineffective governance in the enterprise .
In the pre-service world, there was closer coupling between the developers. The monoliths with a shared code base would force a certain governance.
If the software is written in Python, writing a module in C++ would need to be justified. If the enterprise is using an Oracle database, a Postgress database would also need to be justified.
Developers can’t just release individual modules onto production. But with Microservices, these scenarios could easily happen. Having a diversified codebase and tool-base increases friction in the software building process. It may also negatively affect lifecycle costs. These costs will ideally be offset by the gains from those tools. For example, a specific machine learning problem may be solved very quickly in a specialized language, but takes a long time to implement, in a traditional language.
The problem is how much governance does the enterprise apply? If it’s too much it may negate the benefits of using Microservices, because it slows development down . If it’s too little, it may negate the benefits of Microservices as a lot of time will be spent fixing the resulting mess.
Each enterprise has to find their own solution, depending on the business requirements. Factors, like team quality and testing infrastructure may also allow a looser governance. Even in the agile process, roles like architect need to be well defined, that balance developer wants and enterprise needs.
Also technical Solutions should be used to reduce friction and make lifecycle management easier. Sonar Qube and other static code analysers can be used to ensure code quality. White Source provices Open Source inventorization and lifecycle management, Continuous build and deployments are increasing reliability and stability.
Takeaways
Microservices don’t fix the issues in your enterprise. On the contrary it may expose them.
Unclear requirements are exposed because of the looser coupling of microservices. A service landscape can help, as well as a defining acceptance criteria for requirements.
If the data model is weak, the resulting microservices will be hard to use. This can be alleviated by defining basic data building blocks.
Intransparent organizations may see their intransparency even increased. The reason is that splitting the teams into smaller units allows even more information hiding. Besides process changes, an accessible API catalog may help.
If an organization is not agile, Microservices can make it agile.
If the workforce in an enterprise doesn’t have the neccessary skills to write a functioning monolith, Microservices will not fix it. They may highlight the skill gap. On the other hands it allows great teams to thrive, by allowing them to innovate faster. Build small, but excellent teams to take advantage of that fact.
If the enterprise has weak governance it can lead to an wildly mixed Microservice landscape. This may not be bad per-se but should be decided before embarking on an Microservice initiative.
When deciding the level of governance speed vs. reliability need to be taken into account.
In Summary Microservices can have great benefits for building a reliable, scalable and agile enterprise, but it won’t fix the underlying issues by themselves.
