Autonomous Units Are Critical for Microservices
Autonomous Units Are Critical for Microservices
In this article, Andreas Lennevi explains how important autonomy is for microservices and how microservices, DevOps, and automation work together in an environment.
Join the DZone community and get the full member experience.Join For Free
Learn why microservices are breaking traditional APM tools that were built for monoliths.
Microservices provide a historical improvement in the way we design, build and manage IT assets. It's probably the most important change in IT in the last 10-20 years. After helping a number of customers with microservices, we see how they make a huge difference in productivity, improving the optimism within the teams that build them: " Autonomous teams owning autonomous components, using a high productivity platform." There's probably no more productive combination than that
Automation in infrastructure, deployments, and operations has reached a level where there is only a small operational cost in having more components. This is thanks to e.g. cloud, CI/CD and hpaPaaS solutions like Mendix. It means that focus for architects and developers can become more functional and IT components can be designed as autonomous business components.
Designing autonomous units is something architects are still struggling with today. Maybe it goes against fundamental principles we were taught about re-use, normalization, and de-duplication. But these are man-made rules, and it's interesting to see what we learn from nature:
Ants, dogs, elephants, and humans all have a head, a body, legs, and feet and/or hands, allowing individuals to operate autonomously. In several cases, groups of individuals work together for a purpose. This is not by accident. These species survived ages of evolutionary competition to still be viable in today's world.
In nature, nobody puts all the heads together in one place. Nobody suggests collecting all the legs of these organisms into one package to 'specialize' on that technical capacity. They would produce nothing. It would never work.
In nature, different species, and individuals within the species specialize in certain functional roles that improve the livelihood of groups and individuals. Copying is common for ultimate efficiency. On the contrary, in IT, the unrestrained desire to re-use things has tied the legs together of many good projects, increasing dependencies, and limiting flexibility and speed.
In the real world, we endorse copying of data every day. Students and co-workers become a lot more efficient when they acquire new skills and learn facts. Copying some data helps them retain knowledge and do what they need to do more efficiently. All schools or workplaces prepare Autonomous Units to live, work, eat, see, run, observe, and invent. To do this, we must copy some functions and some information over. Only the required information in the context of what is needed for a business function is copied, so it is rarely a complete replication.
Nobody suggests re-using knowledge in real-time by running to the expert every time you need a piece of knowledge. No one suggests that we can eliminate going to school because the students could just call the teacher when they need the information. It simply doesn't work and the results would be a slow, co-dependent society. Even the common phrase ' just Google it ' doesn't remove the need for school. As teachers share functions, knowledge, and data with students, they merge the information with their own thinking and background, and new valuable combinations occur.
And yet, too often, we suggest retrieving data in real-time to avoid duplication. In the future, there will be no simple silver-bullets. There may be good reasons to avoid duplication within a single microservice, but if we do not duplicate data and functions between different microservices, the result will be a distributed system with all the problems and dependencies seen in SOA layers and Monoliths.
The innovation is in the combination as much as in the base science and knowledge. In the era of Robotics, let's start in IT by making the IT components as autonomous as possible, and take it from there. Infrastructure is now the commodity and Business Function is the area of innovation.
Organizations that want to get DevOps and microservices right, need to unlearn the habit of ambitious re-use in favor of creating new and awesome combinations. Call them apps, microservices or MSA systems, it does not matter, just make them autonomous and business oriented.
We are moving into the era of DevOps, Microservices, and Robotics:
- We should make IT components as functional and autonomous as possible. This often means having GUI, data, workflow, and logic in the same design module and deployed as one container.
- It makes sense to buy the right level of microservices delivery Automation. A good hpaPaaS removes all mundane tasks of IT delivery, accelerates production, improves quality and reduces risk
Cloud native platforms have scaling, resilience, automation, and monitoring in the package. If you choose a package that does not have this, you risk spending a large portion of time with very techie developers trying to build an automation pipeline that in the end still is less efficient than the native version.
The CICD and Auto-test pipelines will be hard (or impossible) for functionally oriented DevOps teams to manage and keep up to date, losing the essential part where the DevOps can automate its own processes and stay in control of deployments.
Similarly, be very careful with making too small and technical microservices that share databases. It removes the benefit of Business & IT alignment, and the microservices are not truly autonomous. The next blog will cover this important subject.
This article was originally published on the Mendix blog.
Published at DZone with permission of Andreas Lennevi , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.