Monitoring Microservices on AWS Lambda

In the world of serverless computing, numerous companies offer you their services, but even so, most people choose to use Amazon Web Services (AWS). Among the different companies that provide serverless microservices, AWS is likely the most refined out of your choices. Choosing to implement AWS can bring a significant benefit to your company, but be well aware that with this new and efficient way of computing, comes new responsibility as well.

You might ask, “So, what are these new responsibilities and how can I use them to become more efficient?” I invite you to join me as we dive into this topic in order to answer that question together.

Monolithic Architecture and Cloud Microservices Architecture, What’s the Difference?

Monolith

The more traditional monolithic structure can be seen as an “all in one” structure. That means that all of your functions are processed as a chain of data from start to finish in one executable, or "library." Even though it might seem efficient to process your data from start to finish, this can cause more issues than you think. Look at it this way, if part of your code breaks, then your entire application fails, and you will have to go in to write code patches or even worse, rewrite the code from scratch. Once you’ve administered the code patch (or rewrite it in general), you'll have to restart the application from the beginning and hope the patches work correctly. If they don’t, then you’ll have to start over until everything runs smoothly once again.

Microservices

A microservices architecture may seem similar to a monolithic structure by processing functions in similar ways, but its structure is entirely different. Before, a monolithic structure would processes data through stages as a whole, but now cloud microservices takes each of those stages and forms them into smaller independent services, and thus they are called “microservices.”

A benefit to this is that each service also has teams dedicated to working on that service individually. With independent teams working on each function as a service, the amount of time to complete each request will drastically decrease and in turn, make your efficiency increase.

AWS re:Invent 2018

Another way to view a monolithic structure would be if you only had one employee who could work on one task at a time instead of a team of employees working on multiple tasks together. Whereas, serverless microservices would be similar to hiring a team of five employees who can take on one task each. With each employee working on one task, your base of operations has now become five times more efficient. With this new efficient team, you’ll now be able to take on more work and increase your output rate as well.

What’s the Benefit?

Okay, so we’ve gone over the difference between both of the architectures, but what’s the benefit of using microservices instead of a monolith? As stated briefly before, now that each function of your application has been broken up into smaller jobs, this allows each function to be processed and focused on by teams of trained professionals who can process said function in a timely and efficient manner. If this is happening with each of the functions for your application, then you can assuredly see why this is more efficient than the traditional monolithic structure.

To sum it up, instead of just running your code from start to finish, the different functions of your application will be focused on by dedicated services and processed at the same time, just like how a team of five people is more efficient than one person working alone.

A second benefit to microservices is that since each function has a dedicated service, you don’t have to worry about your application coming to a halt just because of one function failing. Instead, you can isolate that function, apply the appropriate action, and then continue as if nothing happened. You'll no longer have to hectically re-write your system code just to keep your application running.

A third benefit is that you don’t have to own physical servers. When you use AWS, all you have to do is send your data to them, and they will process your request as needed. That not only cuts your hardware costs, but it will also cut down your utility bills. Previously, when you had to run applications through your own servers, you not only had to buy your own equipment, but your servers had to run for all hours of the day as well. Not only that, but you had to pay for an IT team to monitor the servers and apply any maintenance that was needed. With AWS, all those needs are now a thing of the past.

New Responsibilities?

Sadly, in this world, not everything can be as easy as you want it to be and the same goes for using AWS. I chose to use the word “responsibilities” as a descriptor because the changes you need to adapt to for AWS are not necessarily seen as negative. What they are though, does take some getting used to with a little learning curve. Even so, with a little hard work, adaptation, and the proper tools, there is nothing to be afraid of.

One of the main differences between monolith and microservices is how you monitor each structure. It goes without saying that any system needs to be monitored in order to keep it working efficiently. Use a car for example; if you own a car, you need to have it maintained regularly. How do you know it needs to be maintained? Well, you monitor its performance. If your car isn’t running as efficiently as you know it can, then you know something needs to be fixed. On the other hand, if you don’t monitor and maintain your car, then it can also break down and leave you stranded.

The same goes for serverless microservices, if you don’t monitor it regularly with microservices health checks, or keep it maintained then you could have a lot of system failures start occurring, and that is not a fun thing to have to handle.

A health check is another way to say that you are running a microservices performance test on your system. Although a true performance test is generally more in-depth, a health test essentially runs the code for each of your functions and makes sure that it is working on a basic level. You can compare it to taking someone’s temperature in order to see if they are sick or not. Again, just because a microservice health check comes back normal, doesn’t mean that your function is working perfectly. Sometimes a deeper performance test is needed.

The downside to AWS monitoring is that you now have to check each of your functions individually. With a monolith, you could monitor all of your functions at once because everything was linked together, and especially so if you were using your own servers. With serverless microservices, you can no longer trace all of your functions together as you did before. That may seem like a downside to microservices, and some will say it is, but with new challenges come new solutions, and with new solutions come new tools.

Tools of the Trade

Some companies took this new challenge to heart and decided to create new microservices platforms that come with useful dashboards.

An excellent example of one of those companies would be Dashbird. The crew at Dashbird saw this new challenge and decided to create a microservices dashboard that will help you keep track of your different functions and their performances.

The services that Dashbird offer not only help you monitor your performance, but they can also monitor the cost of each function and track it’s activity as well. Their services can also help you keep track of errors in your functions as well as alert you to any failures or anything else that needs attention. Another part of their services with the dashboard can help you isolate and debug any part of your code that has become an issue.

You'll also be able to use their dashboard to look into each layer of your application so that you can monitor everything with precision. Essentially, Dashbird has recognized the common responsibilities needed to keep a microservice application running smoothly. With that knowledge, they have created a tool that can help you navigate through the new frontier of serverless microservices.

Conclusion

To conclude, there are obvious benefits to using a microservices architecture instead of the traditional monolithic structure. One obvious advantage is an overall efficiency increase for your applications, while another benefit is that your overhead expenditures will decrease significantly. Although these benefits are great, there come some new responsibilities as well, like how you’ll have to adapt monitoring microservices in a new way. Luckily there are companies out there (like our friends at Dashbird) that offer microservice monitoring tools that can help you make monitoring your applications easy. With that said, switching to AWS might take some getting used to, but the hard work and effort needed to understand it will pay off in the end.