Hello and a warm welcome from my side to the presentation of „Event Driven Architecture in AWS“. I want to show you in the next 10 to 15 minutes how we work.
My name is Walter Huber and I’m the owner and CTO of KaWa commerce, we are an advanced consulting partner for AWS in Austria. We are working a lot with this event-driven architectures and microservices. So you can see here that we have the certification for this, we are an advanced consulting partner, also a solution provider, able to host services for customers in AWS and also we have our certifications in different areas – like solution architects, DevOps and cloud practitioner. We are you happy to show you now how we would achieve the event driven basics of a microservice architecture in AWS.
This is also a kind of tag cloud of what services we love to handle. You can see microservices – this is a tool we really love to work with. The thing is that we saw in the last years, that there is a lot of development and changes in these infrastructure topics. We have different approaches in building applications.
This is one of the things that you see here: the evolution of a service architecture goes from a big monolith – where you have all services included in in one codebase and in one structure of the services – is now moving to different small services with their own API, with their own service architecture, with their own devteam and also with their own databases behind to store the data. The thing is, that now the new approach is kind of serverless architecture – talking to eachother with microservices.
What is a microservice? A microservice is an architectural and organizational approach to software development, where software is composed of small independent services, that communicate over well defined APIs. That means that I have my own service, my own application, a small microservice talking to each other. I’m doing only a small part of my job and this is doing well and this can scale well and is talking to each other with APIs and other ways to communicate. This is the thing which changed in the last years, that it’s not only direct communication via APIs, but it can also be different.
You can see here, the normal way with APIs was that I have a request and I’m waiting for the response. This is okay for different APIs which are working very well, they have some caching layer in it. In some cases, if you have some back end logic – for example in e-commerce some order logic, where you’re doing a request and putting in a new order – there may be some different services behind, which need to get the information from or post the information to. If, for example, you have five back end services which are doing some request, then you have at least – if one service needs 200 ms – together 1 second until the response comes back to the service. The other thing is, if in these five requests one service fails, the whole request fails. This is the disadvantage and the bad thing in synchronous work, when APIs are talking together. They always need to be up and running. The second thing is, if one part of this chain fails, then the whole request can fail – and I need to handle this, that’s the problem.
The other way is asynchronous. Asynchronous has a big advantage because I post a message and say, okay, this is done, do whatever you want with it, if you are finished, I continue my work, give the information back to me and I process it again.
Therefore there are several systems already in the IT section available, for example you have some message brokers available, like Apache Kafka, like RabbitMQ and also redis – in its newest version – has some Pub/Sub possibilities. So this means you have an event bus, where you can post your messages there and every subscriber who needs this information gets this from this event bus. The problem in this case is scalability and also the availability of the service. You have to manage this cluster by yourself, you have to install it, you have to patch it, you also have to update it and also keep an eye on operation to have it up and running. And if it needs to scale, then you have to scale the hardware manually or do other stuff to get the requests into it and to send it to other subscribers. So, this is really cool stuff for event stuff, for message brokers to get messages in and spread out to other services, but there are some things in AWS which are also in this manner and scaling perfectly and always available.
First of all, I want to talk about Lambda. What is Lambda? Lambda is just a piece of code which gets triggered by an event, does something with the data and then pushes the information back. Lambda is really cool in terms of scalability, because I just have my own service – for example I need to resize an image. I get this image, information that the image is now here, I take the image, resize it, save the resized image to another S3 bucket and then the job is done. It doesn’t matter if you do it once a second or 100.000 times a second, the scaling is all done by AWS. This is pretty cool that we have our infrastructure here in AWS – here’s an example of a small Lambda function. This is just a small piece of code which needs to be maintained and this gets triggered by an event. There are several ways to invoke a Lambda function.
First of all, we have some notification services. Amazon SNS is a simple notification service, which gets some event publisher, who then triggers the SNS topic and I get some subscribers, who can subscribe to this topic. That means, that I have some information that – for example in e-commerce – I have a new order, then I don’t care who needs this information, I push it to SNS and say „this is a new order“ and every service who needs this information, is a subscriber of this and gets this information when it’s needed and when it happened – that’s the point.
The second stuff is with SNS – there’s als a queuing service in AWS, SQS. SQS means that I get information in, they queue in this SQS stack, whenever I have time and I have enough resources, then I grab some messages from this queue and work on it. So, a perfect combination for a kind of message broker in AWS is the combination of SNS and SQS.
In this case you can see, I have a topic, which then fans out to two different SQS topics and a Lambda function, which deals with this information. Why do I have to do this? The problem could be, that for example, I have some messages posted in SNS and my information can’t be taken from the other side because there is some maintenance window, there is some update on it, so these messages can then be queued in the SQS. Whenever this function is then up and running again, then I can take this information from the queue, then I can work on it. The second stuff is – for example I have some database behind – there are some restrictions in terms of number of connections and whatnot. So I can also do some throttling on the SQS topic, I say: „No matter how many messages are coming in, if there are 1.000 per second, I can only handle 100 per second, then I can deal it with the SQS queue to work only 100 in one batch.“ Then I have no problem with my database behind. This is also a cool way to handle information from SNS to SQS.
Another thing is AWS EventBridge – it’s pretty new in AWS – and it handles also internal stuff like some changes in the AWS environment when a EC2 instance is generated, when an RDS changes something, then these messages are visible in the EventBridge and you can get this information. But you can also use external services to push information to this EventBridge, so custom messages. This is a cool thing, because the EventBridge takes care of spreading out the information to different subscribers and can handle this and is also in a way kind of a Kafka – to handle messages getting in, like a message bus and then send it out to the subscribers.
Step Functions is also a way to orchestrate information in microservices with event driven architecture. For example, a new order is generated, then you have some services for the delivery, which needs the information, then you maybe have the customer service which needs the information. You need a single point at the bottom where all is done to push another notification to another service and therefore Step Functions is cool, because they can orchestrate and send the final statement. All is done when all steps in these Step Functions are finalized. This is also a way to handle microservices in an event-driven manner.
Also important is for this monitoring and logging. There are some services like X-Ray where you can make these microservices talk together, make them visible. This is also important, because if you have a big architecture with a lot of microservices, then you need to take care to not lose the overview. With this X-Ray you can include it in your code. Then it can handle all these connections together and make it visible where the traffic goes, where the requests are going and what to do if there is a problem.
Last but not least there is also CloudWatch. CloudWatch is a really old and major service of AWS, to make logs visible and also to have metrics visible, because it’s always important to see – for example a queue has too many items which need to be taken care of, or for example if you have some messages which are poisoned which are then redirected to a dead-letter queue, if this queue is getting too big, then you need some information and then you can work with this CloudWatch Magic to have some dashboards and other notifications and all this stuff.
So, the conclusion of this is, that the event based architecture has the big advantage that each service can scale independently. They can scale up and down as they need. Every service has it’s own pace, so if it cannot handle more than 100 messages per second, then that’s the way it is, but you can work on it and with the queue you can do it like this. The problem is also in the event-driven thing, that if one system fails, then not the whole stack is failing – this is also a big advantage! In AWS, combined with Kafka classes, you pay only what you need. This is all cost-effective, it scales, if you have 100 requests, you pay only the 100 requests. If you have 100.000 requests, then you pay these 100.000 requests. The orchestration – like mentioned before – can be a challenge, but there are some tools, like the serverless application model, which can then be used to have a framework to build these serverless applications at scale and also deploy them at scale in AWS.
That was a big overview of event-driven architecture and which services you can use in AWS. We are working a lot with them. We are also looking for employees and we have some job offers currently on the devjobs.at platform. If you are curios about working with KaWa commerce, we would be happy to get your information. Just write us, because we need a lot of serverless application developers. We’d be happy to see you soon!
Thank you, for your attention, that was my talk about event driven architecture in AWS. And see you soon!