AWS re:Invent 2023 - Application architecture as code (GBL301) - English version

welcome to GBL 301 application architecture as code I originally gave this talk in German so I'm now re-recording it in English to make it available to a wider audience I'm a senior principal evangelist at AWS working on serverless Automation and in this session I want to take a fresh look at Cloud automation challenge the notion of infrastructure as code a tiny bit and outline a vision for architecture escort when we think about automation usually a picture like this comes to mind and that reminds us that automation isn't exactly a new idea right Ford revolutionized the automotive industry by building the Model T on an assembly line much more efficiently than it could have been done by hand and that often leads to the conception that automation is fundamentally about eff efficiency and although the assembly line was a great invention we need to keep in mind that that was 100 years ago so in the cloud automation plays a much more diverse role and the first aspect of that is speed in a world where we have ever shorter product release cycles and faster Innovation moving quickly is critical thanks to automation you can do things fast and at High quality automation is repeatable the next time something runs it will run exactly the same time as the 900 99 times before them and that gives teams confidence that's important because if teams like confidence they'll hesitate which slows them down or they will not fix items because they're afraid that something else might break more importantly even automation allows teams to work entirely differently when we provision virtual machines manually we would care for them like we care for pets we would try to keep them alive and your feed and maintain them as long as we can with automation you can dispose of and recreate resources as many times as you like and that gives you great advantages because you always have a a fresh and clean image in the resources and last everything that's automated can be measured and what can be measured can also be improved so we should remind ourselves that cloud automation isn't just about efficiency it's not just about reducing toil but it's about working entirely differently with automation playing such an important role in the cloud we could go as far as saying that if you took automation away from the cloud you might end up with not much more than a traditional Data Center and we have very nice data centers at AWS but the whole point of going to the cloud is to get rid of data centers not to get yet another one so looking at the history of automation the term that we commonly use is IAC infrastructure as called and that has to do with the origins of cloud automation a traditional organizational model it has the developers writing application code and then the code is handed over to the infrastructure and operation teams to run it the development teams they focus on the functionality whereas the operation teams they would assure the non-function requirements such as near performance and uptime and for that they would provision infrastructure and they would use scripts to do that and that means that automation was the domain of the infrastructure teams yeah that explains why we use document oriented language like yamala right developers love you know complex expressive languages for the business domains right they love to have object-oriented constructs like inheritance and polymorphism and type systems and all these other Nifty Things but the operations teams they don't have that much complexity so they would have they would beefer simpler languages and you know strings and integers yeah developers would use agile methods and test driven development and do automated refactorings in your IDs Weist you know the operation teams probably happy to use a text editor so respectively each team had the right tools for the purpose and everybody was reasonably happy with the role they played and the tools that they use until sometime late in 2014 when everything changed that was when AWS released Lambda and Lambda really redefined what a modern Cloud application looks like now with servus there is no infrastructure to manage those applications also tend to be more fine grain so how the functions are connected now matters a lot more the same time automation languages also evolve to become more objectoriented right and on top of all this we have serverless integration services like event bridge that provide application Level functionality like event rooting or event filtering or transformation so suddenly the neat picture from the previous slide was no longer adequate and what we learn is that cloud automation doesn't live in a vacuum it follows the application architecture when Cloud applications evolve to become more fine grained and independent from the underlying infrastructure the cloud automation also needs to evolve and go beyond just managing infrastructure and to better understand this shift we can decompose Cloud application you the most well-known purpose of automation is to provision infrastructure and the simple example I use here right you have two VMS then you have a load balancer you have an API Gateway in front of that but actually just on their own these resources steady provision they don't do much you need to deploy some applications or some images on top and still you just have some disconnected resources you need to connect them you need to compose them into a working application and last but not least you probably make some configurations like you know which application talks a primary or a secondary database or you might have different log levels so Cloud automation actually does quite a bit and that breaks down into these four distinct categories now having this model allows us to better understand how the shift to serverless application impacts Cloud automation serverless does infrastructure management for you and deployment has become extremely simple so the focus really shifts to composition and configuration yeah the composition is what connects these Loosely coupled components into a working application and it defines many of the essential properties of a serverless application like its granularity how big or small your functions are and the dependencies between them now many of these connections will use services like Amazon sqs or SNS or event bridge that you configure then to filter and root messages between your sess components and the traditional IAC tools as the name hinted they actually focus more on the bottom half of this picture than on the top half and we can see the issue with that by using a simple example so let's assume you want to trigger a workflow whenever your data in your database Chang right it's a very common use case and it's well supported by aws's serverless services and in this high level architecture you would draw a diagram like this right the data from left to right now the implementation on AWS would use Dynamo DB serverless nosql database and AWS step functions right the Ser as orchestration and workflow tool but the connection between the two that would be done via event Bridge pipes that was released at rain vent 2022 and pipes can fetch the data from the dyn stream DB stream it can filter and transform these events and then based on these events it can trigger step functions workflows but this picture looks a tiny bit different than the picture on the top and that is because event brid pipes has to pull the data so the implementation shows the control Flow versus the picture on the top much more shows the data flow now the implementation in automation languages follows the implementation and that's whether you use a more traditional s cloud formation style or where they use an objectoriented CD Cas stop right you can see here that you can figure event Bridge pipes you can figure a source and a Target but the way you do that is by providing a string you provide the Arn of the respective Source or the target so what we notice is two things right that I first need to translate my architecture into the implementation and then I need to code to that implementation in my automation tool and also we see that the composition right the element that was so important to us that that's not really bad benefiting from the objectoriented library and the type system that that is really still represented by a string and to say that in a bit more Punchy fashion we can use words by cavn Henny who says that these things are stringly typ composition here is stringly typ it's not actually strongly typed the way we would like it to just quickly recap what cdk can do for us here we should notice that now cdk is an object open source object oriented library that he can use for general purpose programming languages right so it's easier to build higher level constructs and because of that you can more easily do things like set up a VPC set up some ec2 instanes and even have complex constructs like a load balanced fargate server that makes you much more efficient because this little example alone would translate into about 450 lines of cloud formation Cod now because we have a general purpose programming language we get ID support with helps and and auto suggest and you can do this across six different programming languages that are supported by cdk so this is a big step ahead and the nice thing about this is that because it's open source and because it's objectoriented the community can create higher level constructs we call these level two and level three constructs and in fact the community is building a L2 construct for event Bridge pipes and that actually uses a type for the source and the target you can see it here there's the ipipe source as a type and as you would expect the Dynamo DB stream source implements the type so that is quite nice this is strongly typed this is no longer stringly typed Now using the type system is a great step ahead but it's only part of the picture when we look at traditional automation languages right when we focus on provisioning infrastructures those resources were generally arranged in a hierarchy I can see two instances part of an autoscaling group and that sits inside a VPC and that is sits again in an availability zone so it need seemed natural for these languages to use the same model of a resource hierarchy but when we look at your modern serous applications they are fine grained and they event driven so they're much more interested in the data flow and the control flow between these components and both both of these models are useful but in different context if I mostly look at infrastructure like virtual machines the hierarchy will be a good meta model to use if I'm building fine grained event driven applications like I would do in a serverless context then I'm much more interested in the topology and the dependencies between my components and this is another major part of the shift in the automation languages so if we try our example again and we sort of want to do this in a 2020 style of programming like we have objectoriented languages fluent apis architecture patterns like pipes and filters and we apply that to our previous example then we should be able to express this using a nice programming model and using patterns like this Enterprise Integration patterns so perhaps I want to split the records that come from the Dynam B and then I want to enrich them with additional Data before I pass them to the step functions workflow now how awesome would it be if the automation code could look exactly like this expressive highlevel architecture where you define a source you define several logical filters and then you define a Target in a nice strongly typed and fluent a pii and now that is exactly what I am working on and the code that you see here reflects this architecture very well the relationship has changed the code is no longer based on the service implementation the code is now based on the highlevel architecture and what I can do it to translate this into the actual implementation I can do that automatically I can use some something that's called a cloud compiler and this is actually it's a prototype but this is running cdk code this will underneath provision event Bridge pipes it will have an Express workflow calling Lambda function for this logical transformation so this actually knows how to map my more architecture oriented specification to the correct services and the correct implementation so if you want to make this more more pronounced this change is that the traditional model makes us Cod to the implementation right it makes us translate first from our architecture to implementation and then again it makes us a manually translate that into the automation Languages by using a high level of abstraction and a different composition model by using this application architecture or this application topology this you know pipes and filters this fluent API I have a very direct mapping from the way I think about my architecture to the way I code the Automation and then I can use automatic translation right we might call this a cloud compiler to then deal with all the nuances and the push versus pull and all these kind of things for me and this is actually a model that's much better suited to fine grained serverless applications so what we have achieved this right we now program our Cloud Automation in a domain model for application topology we use a domain vocabulary of connections and patterns like Splitters and enrichers and that is really a long way from the traditional automation scripts that were mostly there to save us from having to perform manual steps the automation is no longer about it's no longer an afterthought to save manual labor but becomes an integral part on how we think about applications in the cloud and how we develop software in the cloud now if we look at this domain Model A little bit more closely we find that the runtime characteristics of these Distributors asynchronous applications they very much depend on the control flow so let's an event let's take an event Bridge bus as an example so unlike pipes a bus uses a push model so that's a great match for sources like SNS you that processes events at the arrival rate that they come out from SNS and in my little pattern language here I denote that by the little nose the nose Den notes what's the active element what drives in this case SNS drives the events through the event Bridge bus to a destination like sqs but that runtime Behavior can change quite a lot depending on what the target is so one target type supported by event Bridge buses are API destinations right it calls an HTTP endpoint now if you were to call that Endo at the arrival rate of the events that are coming in that would no longer be called an integration that would be called a denial of service attack so so what you need is a rate limiter you need something that calls the API at a prescribed rate but that changes the little nose right this thing now has control is the active threat so to speak at a certain rate of API invocation so now you have a little bit of an issue you have two noses facing each other but luckily there is help for this case because there's an element that has two little nooks and that is called a q a q couples control flow it can take events at whatever the arrival rate is and it can provide those events to the downstream components by whatever rate they fetch it with so now we have a much more expressive way to explain the runtime behavior and how that changes with the targets finally in automation language right the only change here really would be the string of the destination and it wouldn't really represent this huge change in the control flow from a pure push model to a Q and A push and a pull model yeah the only difference we would see there is a string so what we find is that we really don't have quite yet the language like this difference should also be expressed in our domain model not just like with little noses and Nooks but really as types in our type system and we don't really have that vocabulary yet but the good news is those are the things I'm working on when I talk about serous um Automation and application architecture as callede so to take a small breather and to zoom out a bit when we talk about modern Cloud automation languages we can really classify them along three different dimensions right the one is the different language Styles we mentioned right we have document oriented things things like cloud formation we have object oriented Frameworks like cdk and then we also have functional language like for example q and some others are going that route then we also discuss a different composition model right we can either compose based on hierarchy sort of nesting things or we can compose them more along the topology more at the control flow and last is also quite a bit of discussion going on right now whether you should really have separate separate application code and automation code right if they use the same language if you can write both in like python or Java or typescript and they're both object oriented right the natural question should be why does this have to be two different things couldn't I derive my infrastructure from my application code and the keyword there is IFC infrastructure fromc I'm just to reveal where I stand on this is you know I like objectoriented languages because I like type systems and the support that it gives to the developer and the ID things like refactorings and autoc completion and underlines if your types don't match so I like to have those capabilities for fine grained event driven servus applications I feel that the topology is a much better match than the hierarchy but I still like to be explicit about it because my topology really defines important runtime characteristics like how well does my application scale under the load or how does it back off if I'll overload my system I would like to make That explicit and I would like to have the description of that topology be different from the functionality that I code in my application so if you use this as a sort of Meta Meta model of what we're talking about you can sort of map your position and in the picture you see where I would stand on this so what we really achieved and what I hope I was able to convince you of a little bit is that when we build modern Cloud applications we should really rethink the term infrastructure as called and instead we should focus on application architecture and express that application architecture in actual code and perhaps not in a yaml farm so if you like this style of thinking and digging in some of these topics around cloud and automation yeah I like to write books about architecture cloud and platforms and here's actually QR code to a blog post that expands this topic a little bit more thank you very much

Channel: Serverless Land

Views: 3,707

Keywords: AWS, IaC, Serverless

Id: vasvpFRPx9c

Length: 23min 52sec (1432 seconds)

Published: Wed Jan 31 2024