Serverless Governance Best Practices
Organizations that have chosen serverless for their microservices have done so for its cost-effectiveness, scalability, conciseness, and other benefits. Serverless can be a knight in shining armor, but it can also be a double-edged sword.
The challenge of the double-edge sword is this — while the number of microservices grows, the effort in governance grows along with it. Accounting for governance should be considered upfront during the planning phase of your project. Waiting until the implementation phase — or worse, after implementation — can vastly increase the time and effort to add governance into your process.
At Big Compass, we’ve seen up close how out of hand a lack of governance can become. One of our clients had thousands of AWS Lambdas in an AWS environment. Of course, each of these Lambdas takes time and effort to deploy. In an environment like this, determining errors in microservices can be a headache for support and is complicated when there are Lambdas no longer involved in the process. And while many Lambdas do get decommissioned, it’s tough to practice good microservices hygiene with that a Lambdas volume in the thousands. On top of that, a bugfix deployed in one Lambda might mean that same bugfix has to be deployed across numerous different Lambdas with the same bug so a large amount of tech debt is built up over time without good processes for serverless governance.
Several governance lessons can be learned from this use case. First, consolidate and reuse functions when possible, unless you want an unmanageable environment in very short order. Also, your source control and how you develop and push code can be an asset in helping you keep tabs on a growing codebase. You can consider code deployment and asset deletion techniques using IaC tools such as AWS SAM, CloudFormation, or Serverless Framework.
Scope and Best Practices Techniques for Serverless Governance
If you’re looking for strategic ways to handle the governance of your microservices on serverless, these are the scope and best practice techniques that we recommend.
Inventorying your microservices across environments is an indispensable tool that can help you keep track of services scattered across your ecosystem. A good, up-to-date inventory simplifies management and reuse. Self documenting tools such as incorporating your inventory updates in your CI/CD pipeline are a great practice and relieve the burden on developers to remember to constantly update the inventory of services.
Best practice: No matter how many microservices you think you will have, plan for many more and the ownership of those services.
Logging is essential for managing and monitoring. It is not a trivial matter when implemented across distributed microservices. It’s difficult, and it’s nuanced, but logging in a centralized tool purpose-built for log consumption simplifies support and debugging activities.
Best Practices: Logging appropriately to a centralized system enables visibility and monitoring for support and development. At Big Compass, we lean towards ELK for self-starters and Splunk for enterprise organizations.
Visibility and Monitoring
As mentioned, logging provides monitoring and visibility into your services. Even when support and development aren’t actively working a problem, that visibility offers a lot of information, including the health of the microservices and their performance.
Best practices: As mentioned, a good logging solution facilitates both monitoring and visibility. With those in place, you’ll have a better handle on your microservices, can review and tweak performance, and can promote cleaner, healthier environments.
It should go without saying, but access control is a cornerstone of governance. You don’t want just anyone being able to have access to edit, deploy, download, or even delete your services. Security starts with controlling who can manipulate your microservices.
Best Practices: Use an Identity Access Management (IAM) solution to protect your services.
Effectively managing multitudes of microservices across a serverless ecosystem requires proper DevOps processes, including testing automation and a reliable and proven CI/CD pipeline. With your deployment pipeline controlling what goes into the environments, there is a finer level of control without significant ops overhead. Automation offers fewer concerns for collisions and reduces manual deployment time.
Best Practices: Use Infrastructure as Code (IaC) to automate instance creation. Additionally, IaC can also automate tearing down environments and services when they are no longer needed. This feeds back into good microservice hygiene and inventory, as well.
The idea of going serverless is to save time and money while providing a flexible, secure, and stable environment. Without proper governance and planning, your serverless implementation can turn into an overwhelming mess. We at Big Compass love serverless for lots of reasons, and shifting your mindset to managing many small pieces of code and away from monitoring and managing monolithic applications all housed in a single location is a good starting point.
Questions about how and when to begin your governance planning for your serverless microservices implementation? Let Big Compass help you get started on the right foot and avoid adding unnecessary work during and after your serverless implementation.