Modular Monoliths • Simon Brown • GOTO 2018

[Music] get off me can we hear me okay yes so welcome this talk is not cool or hyped or fashionable at all it's about modular monoliths some background says talk right so I'm on Twitter and a number of years ago I said this you know if you can't build decent monoliths don't bother in microservices because I saw a lot of people jumping on mics overseas and they were just bound to fail and I thought that was lots of wisdom and so did 305 other people exactly however hold your applause I got completely outclassed by the architect cliffie I see you have a poly structure monolith would you like me to convert it into a poly structure set of microservices 4,000 so I can magnitude more the other way to look at this is that and that's essentially what this talks all about for those you who don't know me my name's Simon Brown I am an independent consultant specializing in software architecture I'm the author of a couple of software architecture books that you can find on lean pub comm I also wrote a chapter in Uncle Bob Martin's clean architecture book recently the chapter is called the missing chapter it is there because I do have a copy and all of the stuff in the missing chapters essentially what this talk is about as well in addition to all of this stuff I am the creator of the c4 model which I'll explain in a second but in a nutshell it's a hierarchical set of architecture diagrams to describe software architecture systems and I am the founder / chief code monkey / everything else of a company called structure Iser which is a set of tooling to create octave diagrams why do I bring these two things up first of all is the structure Iser stuff the server side is basically to Java spring and we see web applications - modular monoliths running on pivotal Web Services cloud foundry platform so all of the stuff I'm talking about in this talk I'm actually using myself we often call this dog fooding which is a horrible but there we go I'm not using docker or communities or microsomes or anything like that so again this is all old-fashioned stuff and furthermore if you have a good code structure it's easy to visualize it so that's kind of where I'm more interested in this module monolith stuff from c4 c4 is my diagramming technique its context containers components in code and you can find more information about that at c4 model comm to give you a quick introduction so this is a system context diagram for a system I built once upon a time basically I built this thing here as different types of users and different system connections we zoom into that system and we show the containers inside it by container I mean application or datastore so here we can see that there's a web application another java application and a bunch of data store things we zoom into this content update at this java application and we get to see the components inside that java application again it's nice and easy it's all nice and hierarchical you'll notice in the top right corner there is a tweet component now the tweets component in this case it is just responsible for putting tweets into a data store and getting tweets out again so this is level 3 of my C for diagrams so we zoom in to this single box the tweet component and we get to see the code that implements it now what have you noticed well on the previous diagram there was one box called tweet component and now I've shown you the code there is not one box called tweet component it's gone tweet component does not actually exist where is it gone the tweet component is actually a bunch of Java interfaces in this case and Java classes across a layered architecture so we had this really nice simple story unfolding and then we've got to this final code level the story stopped working and it's at this point where people say well this doesn't actually because you know that tweet component exists conceptually yes I guess so I mean it's a conceptual grouping of a bunch of Java interfaces and classes but that's not the point here the point here is that any abstractions we use to describe our software should reflect the code and vice versa and that's essentially what this talk is all about there's a great book about software architecture I'll I'll refer to called just enough software architecture by George Fairbanks in this book George talks about what he calls the model code gap so pick to the scene you are at work you're having an architecture discussion with your friends and colleagues and during this discussion you're going to be using words like module component service subsystem layer who's a Java developer you a good chunky excellent so in Java we often talk about building layered applications yeah does Java have a layer keyword Oh does Java have a component keyword not really and that's the problem the languages that we use and this applies to most other languages as well the languages we use do not have these architectural constructs as first-class citizens as first-class keywords then this is the model code gap so we talked about a module or a service or a layer and if you can't map these concepts into the code base there's a mismatch isn't there a mismatch between these two ways of thinking bottom-up versus top-down this is the model code gap the other way to think about this is imagine I asked you to draw me an architecture diagram of your software you will probably draw me a quite high level picture modules components layer services etc and how they interact her runtime if I were to find some tooling to reverse engineer a diagram from your actual code base I'm not going to get the same diagram am I I'm going to get a very low level very precise diagram showing me classes interfaces folders files namespaces package hierarchies and so on again this is potentially the moral code gap the model for that the model code gap manifests itself in a number of different ways one of these is very simply this you go and ask organizations show me your architecture diagrams and then they have these wonderful looking very colorful architecture diagrams sometimes and then they ask the development team do these make sense and they don't know because they don't match our code then this happens a lot and that's the thing I want to try and fix here as well in the book george fairbanks says one of the ways we can address this model code gap is to adopt an architectural e evident coding style now this sounds very grand but basically it's just saying that the code structure should reflect the architectural intent so there's a nice clean mapping between how we think about our system from a kind of top-down perspective and what the code ends up looking like and being structured so this brings me on to how to restructure code and of course there are lots of different ways to do this so I'm going to walk through a bunch of the more common ways to organize in this case Java code but a lot of like what I'm going to talk about applies to many other languages as well the first of these is called packaged by layer and what we're trying to do here is we're trying to organize code base to form what it does from a technical perspective so hopefully if you seen this a million times before this is a typically a horizontal style of slicing of packaging of layering and you end up with code bases looking like this so imagine we are building a web application doing something with orders you might have some sort of web layer up here and orders controller doing webby stuff you might have some business service thing here like an order service and they might have some data stuff at the bottom all familiar with this good you got different types of layered architectures you've got the relaxed versus strict approaches to layering the difference is essentially how many levels how many layers down can you call do you call just that directly just the layers directly beneath you or can you skip around layers this is the difference between straight and relaxed why do we do this why have we done this and the answer is everybody tells us to so you go and read a book on spring in this case and it says yeah organize your code like this and it's a bunch of layers you turn the page over it tells you why separation concerns testability etc etc additionally sample code bases every time you download a sample code base for some new framework they typically are structured in a nice easy way to understand typically layered rock textures any demos you see at conferences are typically layered architectures as well and so on and so forth there's something called cargo cult programming which you may have come across before amazing this is doing stuff because you think you should be don't really why and I think layered architectures and structuring our code as a set of layers falls into this category a number of times and we often don't think very carefully about why we're doing is we just kind of do it because we think we should because that's how everybody else does this uncle bob martin a number of years ago i wrote this great blog post called screaming architecture and he basically said if you look at most enterprise code bases they all look the same web stuff business stuff data stuff and that's typically reflected in the top-level structure of the folders and packages and namespaces and the co elements and he says this is not the way that the building world works so if you look at the set of blueprints for a library or a house or museum you can tell it's a library or a house or in resume just by looking at the blueprints and so this leads us on to something else Martin Fowler said a similar thing as well he said this layered architecture this layered code structuring is a good way to start it's nice and easy it's easy to explain to people however once you get to scale your product to scale your project you now have to start thinking about modularity inside the layers so rather than chopping your cut out like this maybe you need to chop it up in a different manner the other thing to bear in mind here is if you do have a layered architecture like you're building a web application and you want to add a field to our webpage you end up changing stuff in the web page and then a web controller stuff and then the base in the business or service layer and also in the data layer so many changes that we make to our software systems actually go across all layers anyway so a layered architecture is not a particularly good or efficient way to structure code as well from those perspectives alternative approaches number two package by feature so this is basically flipping the whole thing 90 degrees and rather than organizing our code and grouping our code by technical thing we're now doing it by functional thing feature set aggregate routes there are a number of ways we can slice our codebase up vertically if you want to say that how you do this is of course entirely up to you but it is that vertical slicing so we're grouping together things related to a certain feature set or I could go route for example this is what it might look like so rather than having our orders functionality split across web packages business packages data packages we throw it all together in a single orders package is this better than packaged by layer debatable it's just different one of the cited benefits includes it's being it's easy to find code related to orders I guess I because there's a wall in one place however with modern ideas you can use searching so a lot of these arguments not that great to be honest you do get higher cohesion because all of your order stuff is in one place now one of the big problems with this way to structure code is that if you have orders and customers and you need to have a link between the two where do you make that link so there are some interesting side effects and caveats to package by feature for example sometimes when I apology ensues and I say you know who does package by layer and nobody says anything and I say who does package by feature in a few more hands go up and then you asked who does ports adapters and many more hands go up and this seems to be a much more common approach to structuring monolithic applications these days supply ports and actors essentially what you're trying to do here is you're trying to keep your domain related business code separate from your technical or infrastructure related code and the way this works is that there's an inside and an outside and there are a number of different approaches and themes on basically this core central idea some of them you may have heard of for hexagonal architectures clean architectures and in architectures and some one so forth so you have an outside which is about your technology and your interfaces with the outside world and you have an inside which is about your business domain so the inside is technology agnostic those of you familiar with the main different design you're typically expressing the concepts on the inside in terms of that ddd ubiquitous language so customer's orders products etc and the outside is the text specific stuff so when you're writing interfaces and adapters to databases and external parties and api is that's where that code lives and there's one rule here essentially the outside depends on the inside never the other way around so it looks like this you have two domain stuff in the middle your infrastructure stuff on the outside and all the defense the arrows point inwards and this is what it might look like from a kind of class diagram perspective in Java just this package here represents the domain stuff on the inside and the arrows again point inwards I suspect that this approach to structuring code is also cargo coltd a lot and one of the reasons I say this is because not all frameworks are created equal and what I mean by this is it's easier to wrap up some frameworks and some interactions with the outside world than others so imagine you are building a web application and your web application has 100 different pages that you display to the user you have to basically create 100 adapters and wrappers one per page essentially if all of your 100 pages end up talking to three or four tables in a database it's easier to wrap up three or four tables on a database then provide wrappers and adapters into 100 web pages so you have to be careful about taking ports and adapters of face value because you might end up writing lots of adapter code and abstraction code that's not really necessary I have seen people for example wrap up frameworks like spring MVC so spring MVC kind of sits in this outside and then they add additional abstractions on top of spring MVC to make sure that their domain code is not dependent upon spring MVC and if you're thinking that's nuts it is because spring MVC already provides a nice simple abstraction over HTTP so you're kind of wrapping up the wrapping up the wrapping up so just basically carefully this is what I'm saying having said all of this right so let's go back to our simple latex I led example so we have this code we have web stuff business stuff data stuff and you have a nice big system thousands of lines of codes all working great somebody new joins your team and you say ah hello I've got a great feature nice introductory feature it's not too tricky I'd like you to add it to the codebase the new person comes on they download a copy the source code they have a look through the source code they try to figure out what's going on and they say yeah I think I know how to add this feature and they take this and they do that yeah this might be the best way to implement that feature or it might not and maybe you had a principal on your team that says make sure we have a strict layered approach and we don't cut start by passing layers but if you didn't tell that to you new new joiner they might do that because they think it's a more efficient and if left unchecked you get that happen one of the problems with languages like Java is that what people typically do is you know this might be a Java package and this might be a separate Java package in order for this thing to talk to this thing in a separate package this thing has to be public once this thing is public it can be called from here but also it can also be called from anywhere else in your codebase you see the same with c-sharp and the internal key work for example so again you do have to be a bit careful here and this is what we typically get to the big ball of mud it's a haphazardly structured system and I love this bit dictated more by expediency so we knew in a hurry to add stuff to your codebase yeah we'll do the things that quickest way we possibly can and maybe that's not good for the long term structure of your codebase the longevity of your codebase so it's at this point somebody says we'll hang on a second we don't really do this in the real world because what we have on our team is a set of architectural principles and these architectural allow us to introduce constraints and guidelines and boundaries and through these architectural principles people won't make those shortcuts and these architectural principles typically say stuff like that so web controllers should never talk to data access repositories directly this will almost go through these services layer maybe seen these sorts principles in use yeah and then you ask people how do you enforce this and their faces go blank and they go oh I know how to answer this question we trust our developers because we're agile yes and how does that work out for you and in some cases this works beautifully right don't get me wrong there are definitely teams I've worked with who can do this and they're fantastic for the rest of us yeah we're all human and if we need to move fast we might start taking some shortcuts and if we were on the scrum train and we tried to sprint sprint sprint deliver deliver deliver we might take more shortcuts and we've apps really should do and then we get a few weeks in and we go we need a refactoring spring because our code base is a bit of a mess now sorry so this is the stuff you have to watch out for it is however 2018 and given it is 2018 and we have all this machine learning and AI stuff we should be able to build some tooling that helps us build well-structured code bases in other words we should be able to use tools that help us create nicely structured code bases does it redo this it's like one personally this is not a common thing there's a book that was released recently called building evolutionary architectures and in that book they talk about Fitness functions and fitness functions are the quite broad in nature and you can use them for in quality attributes scalability performance security that sort of things part of your build process you can also use Fitness functions as a way to assert something about the fitness of your code base so cyclomatic complexity coupling and so on and so forth and one of the ways to do this of course is to use tooling and there are a number of tools out there that can help you create some fitness functions that run a surgeon's on how good or bad objectively your code is static analysis tools and you have a bunch of architecture violation checking tools so I'm thinking about things like JQ assistant they can write rules with arcs Java arc unit and so on and so forth and what you can do with these tools is you can start to define rules that look a bit like this so it's the same thing as the architectural principles you know types in star saw slash web our web package should not have access to star star slash data stuff in our data access package and you integrate these things with your build process and hopefully somebody does something silly you'll put breaks and then you turn this rule off because it's annoying but that's a different story yeah we all do that right adding your tests I do kind of like this idea because this this gets us a bit better than where we are today however it feels like a horrible hack so we have to write a bunch of external tooling to verify the actual tooling we're building is of a decent quality and that just doesn't really sit well with me because we can turn it off so what's the answer and the answer is maybe we need to get better at using the tools we have available to us today like the compiler and it's at this point people will ultimately say well hang on a second if you're talking about you know Java and using the compiler and access modifiers Java's flawed they say why is Java flawed and they'll give you all of the reasons why Java is for my kind of access modifier perspective you know we don't have so if you if you have a package there's no kind of sub package thing in Java and she you very quickly get to explore the different flaws of the Java packaging system and access modifiers and things like this and that's fair to an extent however that's what we have and unless you want to go and writes new languages that have first-class keywords like layer and service and components then maybe we should just try and figure out how to use we've got now so with this in mind I have another option for you and this option is what I call package by component and it's really a kind of hybrid approach to package by layer and package by feature and what I'm really trying to do here is I'm trying to bundle together all of the code that belongs to our component in the same place what I mean by components because this is a horribly hugely overloaded term what I mean by component is essentially this it's a grouping of related functionality hopefully behind a nice clean simple interface and this component runs inside something like an application if you're wondering where this came from it comes from the abstractions behind my c4 diagram overall so a software system is made up of containers not docker about applications and data source authorities containers contain components components are built from code elements so what I'm trying to do essentially is get the architecture view of the world to marry up with the code structure and the code view of the world and package by component basically looks like this so my personal preference here and there are different ways to do this but my personal preference is always to keep the kind of UI related stuff whether that's web UI eyes or ap is separate from the non visual stuff so if I'm building some orders from County there's an orders controller doing orders web stuff and there's a whole bunch of non-visual orders related functionality so business service stuff business logic and data access so this whole thing I'm going to call an order component what I'm trying to do here is essentially apply component based thinking to monolithic code base so this is good old-fashioned component based thinking component based design applied to monolithic code bases and what I'm trying to do here essentially is apply modularity as a guiding principle to a lot of the architectural and therefore code structured decisions I end up making so I'm always thinking what are the big coarse-grained things that I would like my system to be made out of what are the high-level structural building blocks essentially of maimana monolithic application the other way to look at this is basically I'm separating interface from implementation this is another good old-fashioned design technique interestingly this is exactly what we see with micro-services isn't it so with package by component I'm going to have some sort of interface some sort of public Java interface and a whole bunch of package protected implementation code with the microservice I'm going to have again some sort of public interface Jason over HTTP messaging whatever some sort of networked public API and a whole bunch of private implementation code the you can't see inside of so if I have an orders micro service you can't call my data layer inside the orders Micra so it's hidden behind the public API the same thing is true of what I'm trying to do with package by component so I might have a bunch of classes and interfaces sight inside my java components but you can't get access to this because I'm going to use Javas package protection mechanism and hide it from the outside world so this is one component per java package it's about putting some boundaries some impermeable Rize round my code so this is all very easy to do all right but the devil is in the implementation details so you can come all the way through this story and have a bunch of really nice ideas about how you want to structure your code base and then it all falls down that last hurdle and you end up with the big ball of mud and you don't really know how that happened and the reason often happens is because of our friends the public key word the number of times even even literally late last week I went through some of my own code and I was reading I was like this thing does not need to be public delete we just type public by default and I don't know why it's muscle memory a lot of the tooling we use you know IDs you go through wizards and they create you a bunch of public classes like stop doing that just stop using the public key when it's not necessary half the time what's the problem the public key word there's a big difference between organizing code and encapsulating code and the problem we're using the public key word is you're really missing out on many of the benefits related to encapsulation well these two concepts are very very different I've given you four examples of some orders related functionality number one package by layer number two package by feature number three ports and adapters number for my package by a component approach if we take these four simple examples and we assume that all of those interfaces and classes are made public so again this is has a java slot but you can apply this to other languages if we if we make the assumption all of these types in the examples are public you get four versions of the same thing that are very conceptually different so they're conceptually different architectural styles and structures but they're actually syntactic identical so here are the four examples laid out side by side packs bilayer picks my future ports and adapters package by component if we make this assumption to all of these types in these packages of public all we are using these packages for is organization their like folders we have no encapsulation going on here whatsoever so if we remove these packages from these class diagrams you get that they're all the same it's a neat trick isn't it this goes a long way to explaining how sometimes when I look at say a ports and adapters code base it looks like a layered architecture and often it is because let all the arrows match up you're just dumping public classes in different packages but there's no encapsulation there so you have to be super careful with the use of the public key word we have access modifiers though in Java and other languages so if we use the access modifiers appropriately we can start to draw some very different pictures so I'm going to bring back the packages onto this diagram and I'm going to fade out I'm going to grayed out the implementation types that could potentially be made Java package protected and therefore hidden outside that package you kind of have to work this through in your head so in the layered architecture example this orders controller needs access to this order service so this service interface needs to be public the implementation class can actually be packaged protected if you're wondering how do you instantiate a package protected class ask Spring you'll do it for you in all over this service implementation class to use this orders repository the interface needs to be public implementation cost can again be package protected with package by feature you need some sort of public entry point into that package and everything else can be hidden from the outside world assuming no other slice needs access to stuff in this orders package with the ports and adapters architecture that thing again needs to be made public because it's accessible by the outside world this interface needs to be made public the implementation class can be packaged protected and this interface needs to be public because it's it's dependent upon by this potentially package protected in relation costs sitting outside in port in my package my component again that thing is just public and we have a public interface here and a bunch of package protected implementation code so now you can see they're actually layered architectures and ports adapters are not that different depending on how you look at them whereas these other two versions are quite different and that's the thing it's always worth having some extra thinking time and making sure that the way you actually implement in structural code matches back to how you intend you're arctor to look from a top-down perspective and one of the things I think you should do here is use encapsulation and really use encapsulation to minimize the number of potential dependencies if you have a code base and everything is public everything can be called from everything else and you get lots of potential dependencies once you start hiding code and using information hiding in a capsulation you can only have dependencies on public things the fewer public things you have the fewer potential dependencies you can have and the other way to look at it is this the surface area of any internal public API should match your architectural intent so if you have an active diagram that as a set of components or modules and layers make sure your code reflects that then that people can't bypass what you considered to be a module or component and start accessing internals directly so base what I'm saying here is if you are building one ethic application you do have some options here to use the compiler to enforce some of your architectural boundaries and your architectural ideas in the tent this is like the simple version of the whole story because once you kind of take these ideas you can go you can go a number of steps further and there are other ways to diiie couple code elements for example you can use a module framework like the the new / old Java 9 module framework that people are not using it the Java module framework allows you to distinguish public types from published types so you can write your entire code base as a bunch of public types and when you create your module manifest you only export and publish specific subsets of those types if anybody tries to use your public types that are not published they can't do that so there are module frameworks out there that allow you to again create this distinction this 2d couple interface from implementation you could also go further and split your source tree into multiple parts so multiple maven modules great great Draven obviously graving a grade on modules and so on and so forth so you have one source code tree per thing per module per layer whatever you do have to careful with this if you are doing ports and adapters you know having separate source trees is I think a recommended approach because one of the anti patents I see with ports and adapters style architectures is you have two code bases one for the stuff in the middle and one for everything else around the outside so you have like a domain source tree and an infrastructure source tree and the problem with doing this is if you have one source tree with all of your infrastructure code it's very easy for infrastructure code to talk to each other so again if you slice your ports and adapters code straight into multiple code trees you can stop this thing happening at compile time for example the problem of doing this is there lots of trade-offs because the more source trees you have slower and more complicated your build process gets so there's probably some sweet spot depending what it is you building in the sizing of let's see of the thing you're building more generally of course every decoupling mode has different trade-offs and this is where we actually get back to Microsoft in because micro-services is if you like the ultimate decoupling mode isn't it rather than having a bunch of code kind of sitting in the same process with some boundaries around it you've got separate processes with essentially networks in the way so that's the ultimate decoupling mode but there are a bunch of trade-offs associated with doing that and this raises a rather tricky question how do you know what style of architecture suits you do you go from monolith or do you go from my trousseau versus and unfortunately I see lots of people jumping on micros for reasons around fashion and hype and they're failing this is what George Fairbanks again in his book called architecture in different designs so choosing an architecture choosing the soil just because why not and not really thinking through the trade-offs and the caveats about about that particular architectural choice one of the things I recommend people do is use agility as a quality attribute so quality attributes are things like performance the scaling and availability and so on what about agility so how fast you need to move as a team and which parts of your code base which parts of your system need to move fast which parts of your code base are potentially more volatile than others and maybe you use this information as a way to make a much more informed decision so maybe you have the bulk of your code in a monolith and a bunch of smaller services around the edge that need that volatility or that needs to be able to change with that volatility rather and in all all of this a good architecture gives you a deity and again this kind of makes sense doesn't it if you ever seen those big horrible code bases the big balls of mud the spaghetti code systems when you change something here a whole bunch of stuff here breaks and you don't know why and it slows you down a good architecture gives you a Jill T what I mean by a good architecture this is somewhat subjective but what I mean by a good architect is something with I'm modularity it's something that has a good well-defined structure and one the promise here is you don't get that for free so you have to put some upfront thinking let's call it upfront design to come to a nice well-defined structure and this is one of the reasons why people jump on mike rizzo verses because microservices gives you a strategy for decomposition and modularity it's a bunch of separate processes running around on your network so people use micro services architectures to enforce code boundaries and in many of the conference talk certainly over the past few years you always find people comparing this thing to these things down here these horrible monolithic big balls of mud and that's really unfair I mean historically monolithic applications have looked like this I would definitely grant you that but this is a really unfair comparison because what I see a lot of people do is they say we have one of these and we've been building one of these for 10 or 15 years and it is a mess and we can't change it's just too slow to add features now so what we're going to do is rewrite it from scratch in that style I can see people going no really yeah I've had a number of organizations I've spoken to this year who basically told me these this exact story and what then 14 end up doing is they end up taking their approach to building that and they stick typically synchronous HTTP calls between the things in the monolith and they end up with that and furthermore all of this has to be lockstep deployed but hey we do micro services on door kubernetes CV driven design so you know basically they end up with a distributed version well there before which is really poorly performing and so on and so forth now this is a much fairer comparison I would like people to maybe just do this first so as I've described you during this talk it is possible to create modular monoliths you have to a bit of thinking into this you have to make that your code structure reflects to architectural ideas in the tenth and again you use agility as a quality attribute maybe have most of your features in that thing and you have a bunch of services floating around the edge where that makes sense there's a slightly harder part of all of this I'm going to skip over and that is actually doing design and people say well how do you design software I'm like we've done this before go look at Wikipedia and you show them the page about decomposition like oh that's interesting yes and you tell them there are different ways to decompose a thing into smaller things I didn't know that either and it appears that we've lost the ability to describe how we actually do design why people just do design but they can't tell you the underlying principles about how they do design you know but it's functional decomposition or volatility based decomposition and so on and so forth and then whenever you go to microservices talk these days people end up talking about partners and they end up showing a screenshot of this paper and they they cross out the word modulo and and yes throw service or micro service in there and there's a whole bunch of stuff that we've learnt in the past this is from the 70s really interesting papers you definitely read it and there's a whole bunch of interesting stuff in the past about good design and high cohesion and low coupling and responsibilities and volatility and we've just forgotten it all and all of this stuff applies to every sort of a software system we should ever be building a good architecture gives you agility a good structure gives you agility and then people ask you well how do we even get to a set of things and you say again there's more techniques out there go learn them it says something called CRC it's an old workshop high tech used to be quite well used around the kind of Rupp era Rush unified process fell out fashion it has class in the name classes responsibilities collaborators it's a work shopping technique for doing class tower design we don't do class level design in in meetings anymore but you take this approach and you scrub out this first word and you make it component or module or micro service and you get the same approach you get the same collaborative design approach applied at a high level of abstraction so you get good at design you get good at design you throw stuff into a monolith first once you're happy with your design and your decomposition approach in the monolith then you take stuff out into micro services world if you need to write so Mike services architect just do provide a bunch of benefits agility scalability resilience and so on and so on so on but this is way harder to deal with more moving parts automatic provisioning monitoring log aggregation you also pay more as well so one of the reasons I brought up structure Iser right the starts because it's a start up as a single person startup I want to deliver stuff quick I don't want to be spending months messing around with docker kubernetes log aggregation frameworks and all this stuff I just want to throw stuff on the web and get people using it so structure is too modular monoliths I don't have to deal with all of this stuff yet but I could do if I wanted to so ya choose Mike services if they give you benefits not because your codebase is a mess now because that's not going to fix any problems of course whatever approach you do go for whether it is a monitor monolith or what's that on micro services don't forget about the implementation details so definitely be aware of this overuse of the public key word for example when you're building monolithic applications and definitely be aware of the model code gap so if you ever want to market it to diagrams and make sure they match your code and that is basically that thank you very much [Applause]

Channel: GOTO Conferences

Views: 43,490

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOber, GOTO Berlin, Simon Brown, EventDrivenArchitecture, Software Architecture, Events, Monolith, Microservices, C4 Software Architecture, microservices architecture

Id: 5OjqD-ow8GE

Length: 46min 32sec (2792 seconds)

Published: Thu Nov 22 2018

Reddit Comments

[u/goto-con]

Check out this 47 minute talk from GOTO Berlin 2018 by Simon Brown, Creator of C4 Software Architecture model and Author of Software Architecture for Developers. The full talk abstract can be found below:

If you want evidence that the software development industry is susceptible to fashion, just go and take a look at all of the hype around microservices.
It's everywhere!

For some people microservices is "the next big thing", whereas for others it's simply a lightweight evolution of the big service-oriented architectures that we saw 10 years ago "done right". Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. And this begs the question that if you can’t build a well-structured monolith, what makes you think microservices is the answer?

[u/threecheeseopera]

This guy is the real deal. I've just read his two books (small ones), you can buy them at leanpub. If you are wondering how to be effective in a modern architecture role, read them before digging into TOGAF or Rozanski/Bass/popular architecture texts.