AWS User Group Liverpool #6 - AWS AppMesh

I've been interested in AWS since it was released and read up on EC2, S3 and SQS but never really had much need to really get into them. I have been using S3 storage for around ten years as a bucket in which to store my podcast recordings but that was it.

Out of the three major cloud providers (Amazon, Google & Microsoft) I've always felt an affinity with AWS, probably born out of the fact that it was the first one that I read into. On browsing Meetup recently I came across the AWS User Group Liverpool and so attended the meetup on Thursday.

Although thirteen people had signed up for it there was a total of five of us there, two of which were the meetup organisers! I still don't understand why more people don't attend these free events, there was pizza and beer, like-minded folk and good content as well as having a chance to chat with some of the DoES people and see what they are building.

This evening's presentation was by Paul Gledhill. He gave a brief round-up of what's new in the world of AWS including Quantum Ledger Database (QLDB), Forecast & DeepLens.  Then it was onto the main topic "AWS AppMesh (and what is a service mesh anyway?)".

He started by explaining the evolution of the execution environment, from dedicated servers to virtual machines, into cloud-based VMs, and then containers. When you start to build a large networked system (using microservices or the like) you have a number of cross-cutting concerns that every node in the network needs to deal with such as service discovery, routing, logging, security, etc.

You can either develop these features yourself, or use one of many open-source components out there to help you do it. One set of common services was developed by Netflix and spun out as open source which is now part of the Spring Cloud framework. Some problems with this approach though is that it's heavily java focused, you can interact with it from other languages via various adapters or APIs but they are slow and bulky, also as they are library-based they are compiled into your business logic and so become part of your application deployment.

A newer, cleaner approach is to use a service mesh to provide these features along side your deployed business logic rather than being tightly coupled within it, examples include Istio, Linkerd & Consul Connect, another example launched in March 2019 is AWS App Mesh. App Mesh sits outside of your app container, proxying external traffic to/from your application whilst providing the cross-cutting concerns. This design pattern is called a sidecar proxy as it bolts onto the side of your application container.

AWS App Mesh works across the whole suite of compute services available from AWS, from on-prem hardware, base EC2 instances up to AWS Fargate. However I'm not sure why there is no mention of AWS Lambdas in this diagram.

After we had received this overview of service meshes and AWS App Mesh we had a discussion about if there was a tipping point number of services within your application before a service mesh becomes a valuable viable option. What was interesting was that the more we talked about what solutions it provided the more we were sold that you might as well use it from the beginning regardless of the number of services so that you could concentrate on writing code to solve business problems rather than writing infrastructural code!

It was an excellent evening and I'm really looking forward to the next one, I hope we can gain a larger audience and therefore benefit from the additional experiences that such an audience bring.

Thank you to Paul, Paul and Simon for organising and Amazon for sponsoring.