Governance methodology for micro services explosion

Question

Microservices are the trend now and most of them are developed on cloud. I have a situation where we are decomposing most of monolithic services into domain level microservices. Each problem domain having just a handful of services.

In Amazon cloud each individual services would further realize down as multiple lambda functions. As there would 100s of functions each doing specific kind of activities, deployed by individual pipeline jobs each.

The volume of functions can potentially increase to the order of 1000s in very near future. This in comparison to 40 monolithic apps we have today. Is there any way to group, visualize, account usage metrics, cost etc?

The situation would be similar or complex than the xml hell we saw with earlier version spring framework.

Answer 1

Another possible option which may work very well for your use case is to use a tool called the Serverless Framework (serverless.com). It is the most popular tool for developing applications, is fully open sourced but also provides a management tool that allows you to keep all services in a single git repo if you wish and their CI/CD tool can deploy each service independently. The management tool also includes the ability to manage AWS account for various environments such as QA, staging and production as well as per environment parameter management. All this means that an application composed of many Lambda functions actually becomes easy to handle. I know, I have done it myself many times.

Not to mention they recently launched their new components feature which is a great way to deploy standardised solutions to common problems. Want to deploy a static frontend to an S3 host and CloudFront CDN? Use the website component! Want to deploy a quick cron job, use the cron component. The types of components will only grow over time and you can even add your own.

Answer 2

You do not and should not break up an application into many many many different Lambda functions when there is no requirement to do so. The only reason to have different Lambda functions is if you have different infrastructure or security requirements which you need to enforce.

Lambdas, like any normal function take an event as input, as well as a context. If you are using an API Gateway in-front of your Lambda you will have the path, httpMethod, queryStringParameters etc, as found here. There are many libraries produced by AWS that will mean you don't need to refactor your application code, and can convert this event to a HTTP request your application understands.

One application can be one Lambda function. You can also break up your library dependencies into Layers which can also speed up your deploy as you streamline your CI/CD to get file size limits.

You also don't need to define every API method in API Gateway either and can simply use proxy integration.

IMO this is the only sane way to go about this. As requirements come up you adjust your infrastructure and Lambda accordingly, so if you need one API call to have a longer timeout, you define this method and a new Lambda function. If a reports endpoint for example should only have read permissions, this would again trigger you to make another Lambda function, which may only differ in the iam role you use. Consider using Serverless framework or AWS SAM to cutdown on the boiler plate you need, and would mean you can utilize the same S3 zip file again reducing maintenance.

I strongly discourage you from deploying many different Lambda functions, this will be a nightmare to support, will lead to inconsistencies for a single app, and orchestrating deployments in a way that doesn't break the user experience will be near impossible.

Answer 3

First off you may want to consider a framework such as Chalice if you’re moving to microservices on Lambda. This will help reduce the sprawl of services some but each case is different and all depends on where you draw your bounded contexts.

Speaking from a similar experience to what you’re embarking on, you will want to invest heavily in a few areas. First off having a consistent logging approach is key. You’ll want to ship logs consistently to a single log aggregation service so you can easily query across all services to get metrics. CloudWatch, Sumo Logic, etc can help with this. Also use X-Ray to get more detailed insight.

You will also want to consider adding some automation into your CI/CD pipeline to produce documentation in Swagger or something similar. This should be done in a way that the result is a searchable catalog Of all services with all necessary documentation. My experience has involved doing this with Swagger UI and some custom HTML that gets generated and deployed on each build job.

One last recommendation is to invest in testing. Contract testing and backwards compatibility testing is key to saving yourself from deploying breaking changes. I would also add feature toggles as another key that can go hand and hand here.

Good luck with this effort!

Answer 4

AWS Lambda supports tagging. That is the cleanest way to understand billing on Lambda by tags.

You can tag your microservices for cost allocation and billing.

More on that:

https://docs.aws.amazon.com/lambda/latest/dg/tagging.html

Hope it helps.