Microservices bring changes to every aspect of IT, especially the way IT governance is done. In the words of Michael...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Brunton-Spall, deputy director of technology and operations at Government Digital Service in the U.K., "Microservices trade complicated monoliths for complex interacting systems of simple services."
This complex set of simple services needs to talk to each other and be governed in a way that's different from traditional monoliths. But what does this mean in practice? Let's discuss.
Decentralized microservices governance
Governance with monoliths is centralized. Decisions are made top-down, and rigid control is maintained to ensure uniformity across the organization and the application stack. Over time, this model degenerates, creates a system that becomes technologically and architecturally stagnant and slows down the pace of innovation. Teams are forced to merely conform to the set order of things rather than look for new, creative solutions to problems.
For microservices governance, a decentralized model works best. Just as the application itself is broken down into numerous interdependent services, large, siloed teams are broken down into small, multifunctional teams. This follows the progression from development, testing and IT teams morphing into smaller DevOps teams.
Rather than use the same programming language or technology framework to solve all problems across the organization, teams can use their preferred language and tools to build the services they own. This will lead to a lack of uniformity, which can actually be a benefit rather than a disadvantage. For one, solutions are implemented faster when there is less red tape involved with every decision. And because the team that builds the service owns its implementation and maintenance, there is more ownership over the functioning of the service, and they are able to evolve it to the next level.
So, for applications that are just being created and don't have a history of being monoliths, when does this decentralized governance model kick in? It's not at the minimum viable product (MVP) stage, because, at that point, the app is little more than an idea. However, when an app goes into production, it soon needs to adopt a microservices architecture, and this is when decentralized governance kicks in.
Innovation vs. governance
Speed of innovation is one of the key goals of implementing DevOps. But IT's concern with governance may seem contradictory to this outcome. This is why IT and development teams are often at loggerheads with each other as they try to find the right balance between innovation and practical governance.
However, this is a false dichotomy. Real innovation will not ignore good governance, and great governance should support the best innovation. Therefore, the principle of DevOps where development and operations teams are on the same side and have the same set of priorities and goals is an enabler for good governance.
DevOps teams must understand that with the power to select the platforms and tools of their choice comes the responsibility to toe the line to the corporate standards set by IT. This is why Amazon adopted the motto "you build it, you run it" about a decade ago when it was just starting out as a cloud vendor. Amazon Web Services expected that its developers also share with IT the responsibility for the stability and reliability of the applications and features they ship. This principle has helped propel it to be the leading infrastructure-as-a-service platform today.
One way to speed up governance without sacrificing control is to automate tasks. This kind of automation can happen across different aspects of governance, like security and reliability.
Automating security involves a combination of tactics. A distributed, API-accessible application has more potential entry points for an attacker than does a single large, monolithic app, but typically, these entry points can each be more easily secured using a combination of access control rules, web application firewall (WAF) rules, authentication and rate limits. Automating these tasks takes a modern web server that can handle load balancing, content caching, security policies and more.
One example of such a platform is Nginx Plus. Its ModSecurity WAF protects the application layer against attacks, such as SQL injection, Local File Inclusion, cross‑site scripting and certain types of distributed denial-of-service attacks. This tool can be used to analyze code statically, run penetration tests and fuzzy input against the code and identify common security-related programming errors, such as invalidated input.
For a microservices application to function smoothly, its services need to be able to communicate with each other and work well together. This requires good service discovery. As the underlying nodes or containers that power a service are changed, they need to be identified by the system. This way, services remain visible, and requests can be routed successfully.
Additionally, as requests spike, they can't be handled by a single instance and need to be routed across other instances to share the workload. This type of service discovery and load balancing -- when working together -- enables you to build reliable applications that can take on any workload.
For microservices governance, decentralization is necessary. It provides the innovation and flexibility that developers crave, while maintaining the security and reliability that IT operations folks demand. As you look to govern your applications to make them more reliable and secure, tools that facilitate decentralized governance are the need of the hour.
How combining SOA and web services can improve microservices
Find out why modularity thrives when microservices and SOA come together
Steps to making SOA and microservices work in unison