Mastering the Architecture Mindset with Gregor Hohpe of @amazonwebservices I Postman

[Music] thank you for tuning in to today's episode of the breaking changes podcast i'm your host and chief evangelist for postman kim lane with breaking changes we explore the world of apis through the lens of business and engineering leadership joining me today we have gregor hopi enterprise architect at amazon web services gregor's work with enterprise infrastructure has been the foundational reading for the last 20 years and i find his pragmatic view of architecture and how we deal with change very refreshing let's uh let's start with the basics who are you what do you do oh

what do i do um i'm during the day i'm an enterprise strategist that means that i meet with with aws customers you know discussing the cloud migration but i do a lot more things so i write books around cloud strategy and my favorite topic is the role of architects and architecture and all the stuff that we do i've been following your work for a long time i feel like your books are required reading if you're coming from the soho world but if you're even if you're brand new to the api world i feel like they're

timeless and i definitely recommend the the enterprise integration patterns it's a pretty fundamental bedrock stuff that that i think folks should tune into so what what do you spend your days working on so interestingly yeah the enterprise integration patterns that sort of like classic we wrote this in 2002 so that is 20 years and then it was published in in 2003 so i actually spent a reasonable amount of my time recently re-implementing some of the examples in the book on top of serverless platforms so basically same design ideas so what enterprise integration patterns did if

we sort of teleport ourselves 20 years back right it was eai maybe some early summer days so people started building sort of distributed integrated solutions but it was all very fragmented by different vendors so what we did is define a common vocabulary that helps people design better messaging asynchronous systems now what i did then starting last year is pick that back up so i have 20 years of technology evolution to take advantage of but i found that we're still making you know similar design trade-offs and using those design patterns is still really a good way

about going about getting serverless systems i like it the for me there's a lot of fundamentals in there and it helps me to reread something because i read it back in the day and then re-read it in in today's times because it it it kind of triggers a bunch of emotions and thoughts about how we got here what's different from from then to now how would you see things i know you'd like to see things in terms of constraints as far as like what what what limits us and what what defines how and what we

can build but what what's different from then versus now uh when it comes to api infrastructure and architecture very good question and as i said i'd like to think about the role of architects and architecture so when i consider what we're doing i always see a sort of coming coming from two directions from from two angles the top angle is really you have a certain intent right you're trying to do something and accomplish something and that's where the design patterns really give you a better language to express your intent right like people might say like

oh i put a certain component here name name your favorite product right that doesn't really reveal what you were trying to do very much right that is your choice of service of product so what the patterns from the top down trying to do is they give you language to say oh i was building a message filter meaning right a series of messages goes in and then based on a condition some messages are passed through and others are taken up right now you could say aha you know the reason i use this thing if it's you

know step functions or even bridge or any other of your favorite right this can be yeah any esb kind of product now you can say why you're using this and what you're trying to accomplish and i think that has remained as relevant as ever 20 years later the bottom half that is what products do i have at my hands and you set the keyword so now what constraints am i operating under right we often think we have a blank slate when we do software design but the slate isn't quite as blank right because we don't

want to build everything from scratch but we want to use product or services that are already there or open source projects so we have some legal blocks some building blocks that you're starting with and those blocks come with some constraints right and that's where in the last 20 years things have changed enormously so when we wrote enterprise integration patterns right in order to build any kind of sample application we had to install software to know and you know run things locally and one of the most tedious parts was in order to make a little chord

snippet like this to say like this is what a message filter should look like is like ideally like five lines of code right get a message we apply the predicate if it's true send the message if not don't send right if you want to be very simple about it so those little five lines of code needed like 100 lines of scaffolding right this was all the stuff like getting set up you know message receivers and senders and you know java jvm settings and all the other things around it so the signal to noise ratio was

relatively poor at the time and that has changed a lot right so the constraint of having to install software and you know being dependent on some of the operating system that you're running on your left opc that has pretty much gone away with the serverless solutions right it all runs in the cloud you can go to any kind of cloud shell that you have and basically do everything without ever installing a single thing and the signal to noise ratio has improved enormously right you can use your serverless event routers and you can literally put your

event filter in there and you end up you know maybe not exactly with five lines but maybe you end up with nine or ten or eleven lines so the way we build these kind of solutions has become a lot more expressive because it shows the intent and it gets rid of all the noise well these these constraints have gone away like me having to set up my you know some of the physical ones i used to have to actually rack mount servers and and do a lot of that those things have gone away i don't

have to install as much software but as these things are fading away there's new ones being emerging right new types of constraints i mean serverless isn't free of constraints it it introduces some some new concepts that we have to wrestle with right some new trade-offs yeah and i think we've both been in this industry long enough to sort of see a little bit what what the game they're really playing right we we always have to work within the constraints we have like if you can't get hardware right if you're wrecking and stacking and it takes

you a month you know to get any hardware you will make certain design decisions right you will put as much as you can on the one server that you did get you will you know maintain that thing forever but you will make a lot of design decisions based on that so removing some of these constraints like yeah i can get your compute nodes or the actual functional element right i'm no longer talking about vms or containers i'm now talking about an eventbus an orchestrator a queue uh publish subscribe channel right i can actually get functional

elements that constraint you know goes away what we do though was that the game that we tend to play is so we have a new playground right we can do these things of like hey i can have functional components at any point in time in any form or shape and as many as i need and i only pay for when i actually have traffic what we do is we we push that new approach to the limits because like oh this is fantastic so i want more of it and then we find new constraints and sometimes

we find constraints on the technical side right that we build systems so that ultimately don't work the way we would want to or we had mental constraints so that we build something that we can no longer understand and i see this cycle all the time we sort of in a certain pocket because of technical constraints we make this go away then we shift over here everything seems so much better but then we sort of hit new kind of constraints until we remove those and i think that cycle we've played quite a few times at least

since since i've been in the field yeah there's i mean i've been doing this since the 80s and then the 90s and the 2000s there's i've seen several cycles come and go and i feel like that's helped me see through the change and and address change do you have any other recommendations i mean for teams trying to understand and wrestle with change and deal with these these cycles is it just experience you just have to be in the industry long enough are there other ways we can help help our teams uh deal with this and

this is sort of a very architect question sort of for the slightly tongue-in-cheek definition of the architecture of being the wise person in the corner like you tell us from the many attempts that you had and did you learn anything so i think in this case it's a mix of it's good to be excited about the new technology right as i said like the 20 years it's just day and night right from implementing the same patterns right so we should be very excited and thankful about the modern platforms we have right like you know things

like you know serverless cloud you know microservices architectures you haven't driven things streaming ai i mean all this stuff is just amazing at the same time sort of you need to have an alter ego if you wish which takes a very rational view to it and the way i always think about it when something new comes along i'd like to ask the most simple but most profound questions right the one is which problem does this really make go away or reduce which problems stay and then what new problems does it perhaps introduce right and i

think it's very good to have a balanced view you know what falls into this category let's take microservices right so a very very common thing right well it makes some problems go away it makes the problem of software inventory go away the like you know i have you know nine new modules that work and one that doesn't but i need to ship a single binary so you know i can't do that so it makes that problem go away it also makes the problem of independent scaling largely go away i have a big application some stuff

is pretty benign some stuff is really heavy right before that led to you know very poor hardware utilization so i can separate those pieces scale out the piece that's very heavy and you know sort of leave the other stuff alone um what it doesn't make go away is us having to deal with you know modularity for example i need to structure my thinking and my solution you know a lot of the microservices discussion has now shifted to domain driven design right because having a good designer modularity for your application that is as much needed as

before and then if you look at new problems that it introduces is like well i have more moving parts i have more complex runtime behavior right sort of you know i have then things like circuit breakers where partial failures sort of propagates through my system so there is more things at the runtime that i need to deal with and i think going through this exercise and your head leads to two really important um results the the one is you know it gives you a much more balance a much more let's say architecture kind of mindset

so i guess sometimes i could and here's some things i need to watch out for but it also lets you think about can i achieve similar results with other approaches right it sort of detaches you a little bit from the bus work so let's take the software inventory well if i have a really really good cicd system right and i have really modeled a software so may it still be a monolith but i have really good control over my builds and tests well i can probably reduce my software inventory even with a monolith right because

when i feature flags and other things the one that isn't ready just doesn't go in the other ones do i build i deploy and off i go so it really helps us to not latch on to these buzzwords and say oh everything must be microservices for some reason or another it allows us to see the trade-offs that that we're making and i think that is really key to the architect mindset like shifting some problems we just shift from left to right we make different trade-offs but we should see those clearly so so help me i

like that so help me help me apply that to serverless because that's one area i would say that's that's in the same realm for me i'm trying to understand and explain what the business value is why my my my leadership should be uh investing more in serverless so how do how to walk me through how serverless applies to all this so serverless is a is an interesting one because similar to the microservices it reveals itself at different layers right like microservices started as sort of hey i make my application into smaller pieces but then you

realize that in the end it leads to a different way of actually building software and i think serverless takes that to a whole other other level so the first important comment probably is yeah i just compared serverless to sort of microservices right i come from a very application topology and application structure perspective because i think that helps us really understand too many people you know see serverless sort of oh it's vms it's containers and serverless and i think that's too narrow a view that's just the compute runtime right for one component which the whole point

of serverless is you can have many small components so the interesting thing about serverless is that you have many interconnected small components right and that's where it really moves the needle now that's the architecture point of view how do you translate that into why should my business care right i call this the architect elevator right my other book i wrote writing the architect elevator you have exciting stuff in the engine room well how do you translate that into something that your your boardroom your penthouse should be should be interested in and that's why i think

the economic aspects of serverless play an enormous role and they come in a in a couple of flavors right one flavor is we already mentioned like essentially no setup cost right the thing is just like you need one you have one right you have full automation so no developers are spending you know days and weeks you know patching and configuring and installing stuff right that's obviously really good economics and those economics play out especially well if you run experiments right if you want to build something you know small and quick not having the setup cost

you know can you know bring your overall effort down maybe by by two-thirds or even 90 depending what what you're trying to do the next part that's exciting to the to the penthouse is you have very different economics so if we are honest about normal application delivery the run cost of an application is kind of a black box right you have like 10 vms and the thing runs on there and the 10 vms cost you pretty much the same amount of money every month so you have no insight into your marginal cost so let's say

you have an app that serves like 100 000 users well how much does one user cost you like how much does signing up one more user cost you the real answer is you have absolutely no idea i was talking to an airline right and we know like last two years have been super tough business for airlines so they have a management system for all the aircraft right where's the aircraft maintenance all that kind of stuff as you would imagine and basically because due to the pandemic they went from 100 aircraft down to three aircraft well

now you can guess what happened to the cost per aircraft well the cost per aircraft increased exactly 33 times because the cost was all fixed so that means they have absolutely no way of managing their id infrastructure by unit cost like they have no idea how much does one extra aircraft cost me like they don't know it seems to cost nothing until maybe you have 150 aircraft and then a huge system upgrade comes and somehow strangely the 50th extra aircraft now cost a million dollars because system and hardware upgrades you cannot really manage id like

that so serverless makes all that go away and you can now start to discuss your id cost by function so how much does it cost me to manage one aircraft how much does it cost me to sign up a new customer right is that profitable right is it meaningful for me to reduce the cost of signing up a customer or should i rather reduce the cost of doing the shopping cart or closing a transaction or whatever functional business you might be in and that completely changes the way you look at your software and the the

cost benefit ratio between those is this an effective way for me to look at my legacy infrastructure i mean is is does it give me the technical and the business toolkit i need to to tackle my my legacy systems so legacy is an interesting word like there's anything that was done before yesterday so it tends to be tends to be legacy right so um i worked in silicon valley for a long time and people always said oh you can do everything you want because you have no legacy and i said no no this works differently

we're moving faster so our legacy also arrives more quickly right we have we had legacy problems all the time but we we did something about it so legacy you know there isn't a magic button you can push because the very definition of legacy is generally something that's hard to check but if you have an old system that's easy to maintain and easy to change most people wouldn't call that legacy they're like oh it's just the system that's been really good it's been around for a long time so by definition you know changing something getting something

into a modern setup that is currently legacy is is gonna be difficult i think what we're learning there is a couple of things the lack of transparency is probably sort of the worst part of legacy like you don't know what you're dealing with and you have no safety net it's sort of like walking the high wire in the dark right you can't see what you're doing and when you fall it's gonna be very very painful so what a lot of people do is is a couple of things you know a lot of folks first just

re-platform so like the lift and shift that generally isn't our favorite word right because you sort of get the same old thing in new packaging but it allows you to get a little bit more transparency how does this thing behave at runtime you know i can get some better monitoring observability around it so i can turn one light bulb on at least by shifting this thing to a different platform right and you know sometimes these are you know emulator simulators that run old cobalt things on a linux box and they seem like a clutch and

they are but at least they get you like i said they turn one small light bulb on so you have some idea then on top of that people use incremental approaches so boiling the ocean doesn't tend to work very well with legacy systems so people take one module maybe even sort of a read-only module something that calculates something when i was insurance so calculating quotes was always a good example right it's used a lot because people want to know how much is it going to cost me to buy my car insurance so it's used a

lot and it's kind of sort of stateless mostly stateless right so it's a read-only calculation so people take one small piece out of that and then you can run the systems in parallel you can see if they they behave um similarly and then you can repeat this and serverless is a great target for these things because let's take the quotation well now a i know how much a quotation costs me right so i can decide let's say an aggregator you know insurance aggregator like somebody comparison portal right i want to get insurance you know please

everybody tell me how much it costs i can decide whether it's worth responding or not right because if hardly anybody ever signs up maybe the calls just cost me more money than it's worth so i can make a intelligent decision and in many countries you know car insurance is a very cyclical business many countries have like annual cycles for it so you know i have a traffic spike and it's very quiet the rest of the year so i pay anything if it's the rest of the year so we have some very nice stories where it

can be done it does require some grip though i always tell people right it's not gonna happen overnight yeah serverless is interesting and how it's uh i would say it's helping us address uh in a little more structured way it feels like uh then micro services micro services definitely felt like it was a much it's a much more wild west but micro services have a little bit more more uh set of constraints or logical constraints to it that help us think through this but you mentioned uh monitoring and observability there i feel like would you

say is is that the differentiation between an important one of legacy so anything created yesterday is legacy now but if we have that observability and monitoring and that understanding of how it works is that going to shift what what legacy means in the future like if everything moving forward from here has has monitoring and observability into it and traceability is that going to change what how legacy impacts us and and in in the future um i i think so and for for for a couple of reasons so one thing that can really help us sort

of make legacy less bad is having things run on the common platform right like what you really don't want is the legacy that runs on some piece of hardware that nobody makes anymore they're no more spare parts and if that thing ever breaks there's just like nothing you can do so lifting things on you know whether it's it's the cloud or on premises whatever you choose like lifting it on a common baseline underneath that evolves and it's maintained yeah it takes a lot of the pain out so even though one system might be old and

built very differently from the other one there is some common layer under underneath right and in the past if you were lucky that common layer was ip networking right but now i think we can you know we can have a lot more things in the commonly is it on a standard vm right that is patched does it have common monitoring observability right can i see what the respective systems are doing i think those items can can really help us help us a lot where where i warn folks though as i said in the beginning right

sort of the the problems that go away the problems the stay and the new problems that come is with the new systems yeah in order for them to not become their legacy you need to realize that as you're making smaller runtime pieces right we're basically decomposing our application that started with microservices and then we took it to the next level with serverless or functions as a service right i can now deploy individual functions so we make finer grain solutions and not just that design time we've been doing this long time right at design time we

make classes of methods very fine-grained things now we have to find great things at runtime and as i said it makes many great things you know scalability elasticity of the solutions cost effectiveness etc but i have more moving parts so my runtime now gets its own complexity right and this is now the territory of sort of cueing theory and back pressure and loop loops where you know things sort of basically escalate into a a small problem escalates itself into a large problem and this is exactly where monitoring and observability are the best compensating element right

because we shift some of the complexity into the runtime for good reasons because it gives us capabilities that we like if stuff scales when it's efficient and you know fail safe etc but we need to deal with the new problems that it introduces and that is we have much more complex runtime behavior so in that sense i agree that if you build a solution like this and you don't consider monitoring an overall systems management you probably build tomorrow's legacy very much so so if you have the transparency and the manageability of your solution i believe

you're going to be much better off yeah the i feel like this new world the the micro services and then the push and the server list when you're focused on an individual function or a service uh i feel like i have more control over what's happening and when i have my blinders on and i'm working at that kind of atomic modular level i i get this the cognitive load is is much lighter here than what it was with the monolith but as soon as i pick my head up and look across everything and think of

it you know and go up the elevator as you would say a little bit um i i'm not sure that i have as much control um than i used to that maybe you know devops is getting me um a certain level of control but how would you say my that control or lack of control shapes our world when it comes to how we build systems so i think you can have the same level of control but you need to make a conscious conscious effort so what you know since we talked about enterprise integration patterns and

what has happened in 20 years one thing that hasn't changed as much in 20 years is that when people build integrated solutions they always think about the pieces right well i have these two pieces and i just need to connect them right that's how it always starts right so you very much focus on the pieces and the connection is sort of like yeah well obviously i sort of need a connection to make this thing work but ah you know it's just a line right i have two big boxes in this little line and i think

that's good well we learned 20 years ago and we learned this time and again as your system becomes more decomposed the lines are becoming much more important so i tend to give a talk at conferences where i show two very simple diagrams it's like the boxes a b c d four components and there's two systems that have exactly the same components but they're wired together very differently one is sort of a stack like a layered atox to b talks to c toxic d and the other one is basically fully connected and the two systems have

completely the opposite properties right on the left side very clean architecture i can replace one module very easily but you know long latencies and maybe a single point of failure right if a can only talk to b to c to d if c goes out nobody can talk to d anymore the other system which is fully interconnected has almost exactly the opposite properties it's very resilient if one path goes down everything else still still works right it has shorter latencies but maintainability is poorer because if i want to you know take c out now i

need to redo all the connections to a b and d right and this is a great example i think the lesson we need to learn time and again is the lines are as important as the boxes right the system topology is of equal concern as the boxes are and it's so much easier like you said put the blinders on a little bit where i say oh i just want to work on my one component it's such a tendency we need to actively counter steer that the overall system behavior is is equally important to the behavior

of the small system of the small component and they should get the same attention and tooling right like testing right i test my components yeah traditionally so i test each component i wire them together you know what happens nothing works right that's the classic we always have right like it's the same thing i say like you have a complex system every server the light is green all servers are running but the system is not working right that's how it always ends up the problems end up between the pieces so what i'm a big fan of

is getting the tooling for the overall system to the same level of tooling and discipline that you would use for a single component coming back to the observability and monitoring that is one key part of it and i think the second key part of it is automation right like cloud isn't just sort of another server you know the cloud is about it's programmable right i can get my resource now via api and that's where i spend most of my time when i'm working on serverless solution is can i make it so that i code the

components in my favorite programming language for coding the components but can i code the application topology right how things are wired together can i also code them and the answer is yes like with cdk right which we have from aws and there's sort of a hashi version like a terraform version of cdk right i can do that i can code my application topology and now both layers we talked about the boxes and the lines they both have a programming representation i can start doing unit testing i can do refactoring i can do a lot of

cool things and that's to me most exciting because now finally the two layers get the equal attention and the equal tooling that they deserve that i think is easily underestimated how big that shift is yeah that's going to give us a lot more control over the future and the direction that we go because we're not just at that we're not i don't know it's it's it's a much higher level thinking and we're actually able to see the landscape rather than just we seem to get our blinders on and get stuck at the lower level so

how do you how do you ride the elevator so how do you maintain your your architecture level your high level view and ride in the elevator to the top floors but then also stay relevant by going down to the uh lower force because i know that's a common challenge for architects is you like staying up up here up high how do you how do you understand what's going on on the ground floor and and keep your skills relevant yeah the the view on the food is always better in the penthouse right so some people don't

feel the need to to go back down but yeah the elevator goes up and down right i always say writing it once up that does not count so for me personally i think a couple of things are required the one is you've got to have a natural curiosity you just got to be interested in you know what's going on in the engine room so when i started building the the loan broker that was the example from enterprise integration patterns i'm just like hey i should just you know try this in serverless we have all these

cool tools right i've never used them as much so just curious like what's what's gonna happen right i think that's number number one you gotta have the urge to sort of be connected to reality the good news is and that comes back to our serverless topic in the past trying something out in the engine room was super difficult i remember when when i worked as chief architect before if ever i wanted to do anything hands-on i would pair with somebody else and that had some good reason and the good reason was why i like pair

programming was a great way of knowledge transfer but it also had a pragmatic reason getting a development environment set up for any of our systems would have taken more time than i even had right it would take three days to even write one line of code for me because all the setup now that serverless made go away right you can like sort of download some samples you have some sample cdk it's good like run that well here's your system i'll make a change deploy that well so basically the time to learning and what you want

to do is make a change see what happens learn from that make another change so the time it takes until you get into that mode has gone from like days and days to like maybe minutes or and worst case pace hours right so that's the really really good news the the third part right so you get the curiosity you get you take advantage of the new tech makes your life easier the third part is is there so much debate about should architects code and i generally say yes but for a different reason than encoder codes

and i think that's important so the architect doesn't code to become the best coder right then you should be a developer right i think that's fairly obvious the architect should code so they can understand the trade-offs and constraints better right all the stuff we just talked about so when do you do your coding exercise your goal isn't you know to write better code than the person in the keyboard next to you who does that for a living but to come back with new insight right like things we just said is like ah you know the

serverless thing is great but too many moving parts right it's easy to forget the system image the topology so basically when i do anything serverless i want cdk for example right because i got to be able to program my components to program my topology and that's the way it should be so architects have a different objective when they code right it's not about you know learning you know the latest or library that you might have or you know squeezing the last bit or cpu cycle out of something for us it's taking inside back that we

can then use on on other projects and really learn more about the system structure and how we build good systems what's the what's the best way for a developer say you know with varying levels of experience but start understanding how to program at the the topology level and and and kind of poking around and get curious when they may not have a lot of experience what's the best way for them to to learn at that level so people learn different ways right i like learning by really building something from from scratch i remember like a

couple years ago they can't see hightower wrote a book it was like kubernetes the hard way and a lot of people say like why do you take me through all the details that kubernetes essentially makes go away why do i need to know all this stuff well his answer was very easy he's like well so you actually understand what the thing does right don't just take the magic for granted right start with the pieces like here's how you set up a cluster from scratch and once you understand this you can get to use all the

magic i like that approach very much so from it works for me at least you know i didn't use when i started with a serverless i didn't use any of the sort of magic templates as much i like let me just build this from scratch can i get a you know sort of step functions talk to an sqs cue and can i have lambda consume that and like little struggles here and there right see how this goes and then learn learn from that so that worked well for me like really make baby steps and give

yourself a i would say almost like a controlled experiment environment build something relatively small and you know play around you know change some dials you know put a cue then take the cue out put something else see how that behaves um what that does it overcomes sort of the natural tendency experience engineers that i know when i had like really great time long time ago i got to pay a program with ward cunningham and he was working on a pic chip like tiny eight pin little microcontroller and he intentionally had bought like the cheapest least

capable version that he could find like this thing i think like 32 bytes of ram was something ridiculous right he couldn't do anything but what you find is the really experienced new architects they find a lot of richness in the simple things like he was like finding all these nuances and he was sort of trying ci cd he was debugging with a tv because the thing had no useful output but he could output patterns so he could show the patterns on a on a crt screen because he could emulate the other tv signal and you

might say oh isn't that just sort of geekery is this actually useful and the answer is it's not right so the experienced architects and engineers they find so much richness in a relatively simple setup that they can learn a lot from that that they can use later the novice engineers they always chase bigger and bigger and more complicated things it's like oh we need microservices we need this and we need that and in the end they don't really understand what they built so my advice there is build something small build something that looks simple but

understand the ways in which is actually not simple right like find the odd behaviors find the dynamics see how this thing behaves and that is your real learning because then as you move up to more complex systems you will understand how it works or sometimes it doesn't work and then you actually have a chance to to go fix it versus you use the magic right if the magic show sort of ends like basically there's nothing you can do that's back to the constraints right we're we're under where you we're using constraints to really understand the

space that that we're operating in are existing in and and pushing the boundaries as you said earlier and so that we truly understand what's possible what's not possible and that just really uh helps us truly i think get to the details the technical details of what's happening and it it knows it it teaches you sort of what the boundaries are sort of the the image that comes in my mind you know sometimes we see very sort of simple animals and they just run and then they hit the glass pane right because they can't see as

a glass and they like keep doing this and you're like oh that thing isn't very smart well if i look around the development area i see a lot of the same thing right people like oh i have this new toy it's amazing i'm gonna run with it and it looks really good until you hit the glass pane right you're like oh ouch that didn't work oh what was that let me try again oh ouch right and that just doesn't go anywhere so what the the style of you know development and architecting i described right that

you understand the the mechanics the nuances it keeps you from running into the into the glass well you're like ah here's the sweet spot of this thing this works works well but it works a little bit less well you start to understand sort of what the terrain looks like so versus you know the the novice that's like oh this is like paradise everything is great until it boom right it hits you so versus me like ah it's a little steep over here maybe you know i stay off maybe over there is okay and being able

like you said the constraints the trade-off basically being knowing your terrain understanding your terrain and being able to maneuver on the terrain i think that totally changes the way you you build systems yeah that's uh sounds like a really healthy state of existence uh or relationship with the world around you and especially in technology that can be pretty expensive i mean digital landscape is is is can be pretty vast in endless and so really working hard to make sense of it is is important so how how do you stay so curious and interested in what

you do all the time you've been doing this a while now how do you what are you working on that keeps you so interested and so curious so there's two dangers in the architect elevator right so the one danger is people who never go down right and you know they just become sort of buzzword you know folks you know i wouldn't call them architects so that is not not useful but then the other danger is exactly the opposite once you go down into the engine room you will find so many exciting things like you you

never want to leave right because like you said like the tech universe what is a very exciting and b it's very big and see it's probably also reasonably complex right so all the good ingredients for a person to to to get lost so what what i tend to do is is a as i said right i pick what looks like a simple problem and build it from from scratch right so i i try to stay close to the metal right like really build things up so when for example when i built the loan broker at

the very beginning it didn't have automation even i did anything and everything on the command line just very very simple and then i i ratcheted my way up saying okay well that obviously isn't a good way of doing it so i'd write like cloud formation i tried sam and then i tried um cdk like oh that's like that's the thing i want right so so i made um small baby steps the the other thing that probably helped me i had a specific goal in mind it wasn't like well i need to learn several stuff right

that would have been well that can lead to two results either it's really boring and you don't learn anything or it's really exciting and you never come back right so my goal wasn't to learn serverless right my goal was well implement this loan broker example from enterprise negation patterns build that in a modern modern architecture so i had my my goal my scope and what i wanted out from my engine room what i wanted to bring back i had that defined now did it still get like five times bigger than i thought when i went

in there's of course they did i i blocked on my enterprise integration patterns side and it's like five massive blog posts and i didn't even write down all the pieces and i think in the end it's like 20 000 words like it could have been like a small book almost so you got to understand there's a multiplier factor but you have a certain scope and have something you want to bring back like a learning for you as an architect and i think that puts a helpful boundary box around your engine room adventures i like that

so are we gonna are we gonna get an updated version with with all your recent experiments at some point in the future ah so you mean the updated version for the book yeah so there's the there's a couple of things there so the the website by this enterprise integrationpatterns.com actually what i did is um i published modern examples right i started this a couple of years ago and you know whether this is kafka kafka whether this is the different cloud providers i just said hey there's new implementation examples so what we found is that the

patterns itself and the pattern language hold very well i always said like some of the design guidance and overall you know considerations is expressing intent right like a message field type content filter an aggregator like all these things still exist and they're still useful so the only thing we would need to swap out is the mapping to the implementations so what we're doing there right now is is rather than update the book just have this online it's like so much easier so people can buy the book and get sort of the design intent the trade-offs

and then if you say hey here's what this looks like in serverless right then you just get that get that from from the website what do you do when you're not at the computer and you're not being an architect what what what keeps you interested and curious um so i think there's obviously got to balance it on the left and the right brain so when i'm when i'm not architecting i'm usually out and about i used to do a lot of winter sports okay but i live in asia so that required international travel so so

that's taken a little bit of a hit but yeah i like the outdoors right it gets fresh oxygen in your brain and um i think when you do that the left side of the brain doesn't have to shut off completely it can sort of run in the background and this is where i come up with ideas like the famous article i once wrote is like why starbucks doesn't use two-phase commit right those are the things if you detach from your tech stuff and you go off in the real world but the tech stuff runs a

tiny bit in the background thread you end up with stuff like thinking about two-phase commits when you're at starbucks yeah but most of my hobbies are actually sort of move the body like get outdoors cycle like snowboard um i think that that gives you a good balance yeah no agreed it's and it's essential in these in this kind of covid time i think is to have a have a nice balance and like you said if you have lots of things to think about when you're out there um you know you come back with a fresh

view and and and hopefully an elevated perspective of what's happening correct that's what's what i what keeps me going as well so i i said in the beginning i have sort of a little bit of a double life of multiple jobs and that really relates to seeing things from different levels right so there's the enterprise integration patterns of building serverless stuff very engine room but then i run the other side architect elevator.com right and this is more about you're seeing things from a higher level this is more like the you know the penthouse the boardroom

kind of perspective and the architecture so what also helps me is having more than one tech persona if you wish so sometimes i'm deep in the engine room sometimes i'm still left brain tech stuff right but the architecture of thinking is already it's not so totally left brain actually right it's like thinking about how to explain things better like you said how do you explain this to your company leadership so there's a lot of right brain actually that comes in so i think having a tech persona at different floors of the elevator can also help

you to not sort of get stuck in with this this one little thing so when you're when you're at the higher levels would you say more of your work is having to make it speak to business make the technical speak to business or is it more simplifying and distilling down the tech into simpler terms that that leadership's going to understand so so i think it's it's it's really the combination of both so the biggest problem i see is that when we speak to the business users or higher level executives we we believe we're speaking to

children right we want to make everything like super super simple i'm like hold on you're speaking to the most you're successful and accomplished people in your organization right so why do you assume they can't understand anything and then people say oh but they're not technical and i'm like well define technical right and then like oh they don't know what the hell chart is they're like well that's not technical that's like an arcane piece of technology stuff right they don't need to know but they are very capable of understanding things that i call technical like trade-off

like all the stuff we talked about architectures topologies trade-offs constraints right they understand really well because that's how they run a business right it's the same thing so the key here is to build on the kind of thought patterns that executives tend to do very well right they know how to make decisions they're not trade-offs they know risk they know implications right they know boundaries they know constraints right that's otherwise you wouldn't have a company and then translate your engine room things into those mental models so it's simplifying simplifying as a tricky word right because

in this case yes it is simpler but it's not dummified right it's not sort of oh we should all be agile oh we should all be on microservices right that's what i call dummifying that's not simplify simplifying is finding the right level of abstraction right like the trade-offs we talked about right like micro service and server is fantastic but you're shifting more things to the runtime so you need better runtime tooling right those i guarantee you every business executive for every high level executive will be able to understand that maybe with two or three more

sentences than i just did now but these are trade-offs and balances you can convey so the key is finding higher level of abstractions and they look simply at the surface but they're not simplistic they still allow you to reason about what you're dealing with and i think that's the magic of the elevator it's not about telling the people here one thing and telling the people here another thing that doesn't work right that's called what i would call it lying if you want to be blunt right that's not writing the elevator right writing the elevator is

you're taking what is here and forming useful abstractions that allows people to understand the essence of the decisions we're making here without having to know all the the details that then the product details of the language details underneath and that's what the elevator is about and every time i do this people are super happy because i go finally i can i can understand this stuff like no jargon but actual thinking right you don't want to be hit with jargon like random stuff you want to be hit with a mental model and then i we can

together think in this mental model they're like ah so you know should we move to this thing gradually is this you know the serverless of microservices better for some part of our estate you know should we use it everywhere sort of how do we get this into the organization right is this good for certain markets maybe we have volatile markets is that good there right suddenly you make the part of the thought process and that's when you won right like when you have your executives thinking through the problem with you then that means the elevator

has really worked yeah i think i need to i've been spending a lot of time at enterprise integrationpatterns.com and i think i feel like i need to spend equal time or more at this point right now uh at architect elevator.com because it really i would say this is where i'm at i would say at least for me i'm really trying to learn to speak that language and and and translate it but i'm i want to be riding the elevator back up and down on a regular basis but maybe for a different set of reasons than

an architect would and so i think but i think the architect elevator is is a good place for me to start so thank you for that i appreciate it yeah i hope you i hope you enjoyed it it's a it's a strong metaphor and people really latch latch onto it especially as i said it's about making the connection and going back up and down on occasion so i think their metaphor is becoming quite sticky with soft engineers who you know tend to be frustrated like oh the managers don't understand what i do or they don't

want to support my project or whatever complaint they might have is you know people really start to see okay at least half of the equation is on me right and i need to understand how to bring things to the other levels and they find the architect elevator they're extremely helpful yes definitely well i i appreciate your time today gregory this has been really enlightening um i i definitely want to find some time i could say i would say i'd like to have you back and talk about a whole just session on just the architect elevator

because i think there's a whole a whole world there that that developers and and and folks need to tune into and at least uh think about so i appreciate your time today thanks for joining me yeah thank you for the for the great chat thanks again to gregor for stopping by for more on gregor hopi you can visit enterpriseintegrationpatterns.com or architectelevator.com you can subscribe to the breaking changes podcast at postman.com events breaking dash changes i'm your host kim lang and until next time cheers [Music] you