This year, dbi services attends the AWS re:Invent 2021 conference, in Las Vegas. In the current global health situation, this event has a bit of a unexpected flavor as the previous edition was organized virtually. Having in-person such amazing event is very great !
(yes, we even tried to draw the dbi services logo on that chalkboard 😉 )
Across 3 different beautiful and shiny places, numerous events are organized (1447 listed on the catalog !!) in different session types : bootcamp, breakout sessions, chalk talk, workshop, and many more. They are proposed for a large set of attendees from beginning to experts. Sessions are also covering a very wide range of area, either talks on specific AWS services, best practices, road maps, or use cases.
Decision was very difficult to make the right choice, if right choice there is ! but among all, here a short followup on some sessions I decided to attend.
Modernize from traditional middleware applications to the cloud
Presented by Sabha Parameswaran from AWS, this session started with what he called a warm up. Showing different scenari, we had to chat and brainstorm with next sitting co-attendees and discuss on how we could architect and design AWS based solutions to fit the scenario described.
Key patterns of middleware application deployed on AWS cloud :
- stateless : because easier to scale and easier to recover from failure
- API first
- Prefer event driven application
AWS products and services catalog is large, and highlight was put on choosing the right tool, each of them having a dedicated target. For example, moving from EC2 instances to containers (EKS ECS and Fargate), or using AWS Step functions, AWS Lambda, AWS SQS and AWS EventBridge. There is not one single solution for all needs but a set of best practices, to ensure to adopt the correct mindset for migrating such workloads.
Service connectivity inside and outside the mesh using AWS App Mesh
This session was organized by Mridula Grandhi, also from AWS.
Through discussions, she explained what is mesh, what this AWS service should be used for and all the components of that AWS service. She ended the session by a demo.
Compute workloads have evolved, from standard three-tier architectures to complex microservice-based architectures. Requirements for such modern architectures are Security in communication, Connect : how do you ensure that you are connecting one service to another, Observe : observe how your app behave n to n, see how traffic is going through, and Control : who has to talk to what. Service to service communication becomes more challenging. Service mesh provides a means of monitoring all interservice traffic, and so is aware of all traffic passing through. Using routing capabilities, it is also able to provides traffic control.
In the age of container based solutions, AWS App mesh is adequate to offer such functionalities. Based on Envoy (interested ? check it on https://www.envoyproxy.io/), it is EC2 / EKS / ECS / Fargate friendly. This fully managed service standardizes service communication, simplifies observability and, naturally for an AWS product, is compatible with AWS compute services.
Stay connected and follow us on social media (Linkedin) or on our website! You can also have a look to my beloved colleague Nicolas last post !