Modules or Microservices? - Sander Mak

all right good morning everyone thanks for being here so my name is summer and I have a confession to make I like building monoliths there I said it so feels good to get it off my chest and I have a feeling that there's more people in this room that feel the same way because nowadays if you listen to talks if conferences it's almost only about micro-services rights how to use them Reza use them what technology to use them with and it seems like there's no older architecture anymore than Marco services and I think that's a bad thing not because I think micro services are breath but because I think a lot of people are adopting this micro services architecture without thinking it all the way through and also without looking at some of the alternatives that are out there to actually have some of the same benefits as Marco services without the overhead so this talk will be about one of these alternatives the modular application and modules so a little bit about me I work as a fellow and software architects at luminous which is a software technology company in the Netherlands and at Luminess we both develop products for ourselves as well as for Christmas as consultants and during product developments something that you will find out is that you really want to have maintainable extensible reliable etc software because it's yours you have to run it you have to maintain it not for just one year no for two years before five for maybe 10 years and in that space in that product development space we really turns to modules module systems and modularity as a principle to help us achieve that so I have quite some experience in modular development stacks and mainly in the Java world so giant up until now and with for example Java 9 that has been released a few months ago and we're already having Java 10 we also get a module system in Java we actually got so deep into death in the early access releases that I was asked to write a book about that for a rally and I've forgiven a few for more than a few presentations about this Java module system already and that won't be this talk that's a different talk but sometimes people come up to me after death and they say okay well it's all very nice and ER and this module system but didn't you get the memo we do micro services now so why would we want to use these module stuff so you can consider this talk to be my definitive answer to that question because I do think there's a place for four modules and modularity besides besides micro services now this talk has a question for a title so it would be very unfair to keep you hanging until the ends until they give the answer so without further ado here's the answer modules for micro services yes and of course you're all developers to shoot so you might have interpreted as a exclusive-or but that's not the right way to look at this the way to look at this is as alternatives and options and I hope that after this talk you will see the choice between modules or micro services not as a binary choice but as a spectrum where you can mix and match to your specific situation so the real answer to this question is of course it depends so you can tell I'm consultants because this is always the answer it depends and in the stock we'll look at some of the factors that play into this decision about when to go to micro service rather I want to go and alternative routes so before we do that before we dive into micro services and before we dive into module systems themselves I think it's very important to talk about the principle of modularity itself because this is really something that's key to understanding all of this for this I want to take an example that's not software based so I took this picture well actually I wish I took this picture but I've just found it on the internet and paste it in three slides but here we have the ISS the International Space Station which is a marvel of engineering at least that's what I think if I see this and this is something that has been built over decades by many different teams large teams distributors across the world and somehow it all got together in space and it works it's a single system that works out there so why how did this work because it's such a complex application if you look at it from the outside so it's a complex system so I believe that one of the key principles here is molarity as well because what happened is that these teams around the world they didn't just start doing their thing without thinking no they first defined their interface points between the different modules and yes this space station has modules as well some were built in Russia some were built in the United States and by different people different skill sets different goals different aims but in the end it all came together because they thought about how these modules could interconnect how they could work together and the nice thing is that the Americans they could have completely different interiors in these modules and it could have completely different aims and goals with the modules that they were constructing then for example the Russians but in the end because they had these interface points because they had these interconnects that were well-defined that were agreed upon up front this is something that works now think this doesn't just work for Space Station's this also works for software if we approach our software in the same way then we'll have much better time of creating maintainable extensible and reliable applications so as as far as I'm concerned modularity is the key principle in software architecture and in software development so let's make this a bit more concrete if we look at software developments because well we talked a little bit about interfaces interconnects etc there are three tenets of modularity that we should keep in mind when thinking about software development the first one is all about strong and capsulation and it may sound a bit counterintuitive that the first principle is all about being able to hide stuff because why we want to hide stuff were all about openness we're open source people right we want to know everything over everything but that won't skill that won't work in in the real world when you build complex and large systems you need to be able to say okay this is my private implementation details you don't have to know how I do is you just have to trust me that I can do it in this way and that I will offer to you something that you can use without exactly having to know how it works so strong and capsulation means hiding stuff which is one of the foundations of Morelos of developments now obviously if you hide everything that won't be very useful because then you will have components that actually cannot work together so even though you have implementation details that you want to hide on the flip side you also want to have api's contracts services definitions whatever you want to call it that are explicitly defined and that you share with the outside world and this doesn't only apply to library development this also applies to large applications that we're developing for different subcomponents it's the same problem there so these well-defined interfaces allow these modules that have strongly encapsulated parts to still work together in a useful way now last if you actually apply these principles of creating modules that have encapsulated parts and that have publicly exported api's then you end up with an application that consists of lots of small parts you still need to bring this together into one big hole like they did with the ISS Space Station so in practice if you have these small parts you don't want to combine these into a new system by hand or by sheer luck you want to have some explicit description of how these parts fit together and also something that can be checked hopefully by tools that will help you to see if you have an application that makes sense that's completely so these three tenets of modularity we'll see back in this presentation in different forms because this doesn't say anything yet about what technology you're going to use to achieve this but for us model arity has become the ultimate agile so because if you have modules if you have modular parts in your system it means that you can easily replace internal so he easily can replace implementations as long as you adhere to these well-defined interfaces it means that you can have extensible and maintainable systems by seeing the impact impacts of your changes because you have explicit dependencies between all parts in your system and there are lots more benefits that molarity brings us when looking at agile software developments now I think it's time to talk about marker services now and just keep these principles about molarity that we saw in mind there is no common agreed-upon definition of a marker surface as far as I know so for this talk I'll just use this definition we're going to say that a marker service is a piece of software a software component that's independently deployable somehow and it implements some kind of business capability we're not talking about these little small technical services know these are domain services use like in the drone domain-driven design sets and they do one thing and they do it well that's the micro parts right the crucial bit here is that these micro surfaces interacts with each other over a network and again this is not about the specific thing technology this could be rest over HTTP this could be G RPC this could be queues and events doesn't really matter there's some kind of network and distributive system going on with micro services now what do we see here anyone take a guess now this is the micro services def room at the FOSDEM conference in 2017 and people are excited about Marcus's just right you can see that it's packed Wow well we're gonna fix that because what I see is people looking down in despair right what is this what have I gotten myself into now I see people praying for a better solution this can't be it really so yeah I think we all know that the micro services in our hearts to pull off and that doesn't mean that they're bad thing it just means that it's incredibly harder than doing monolithic development so I think it's very important to reflect upon the question of when to use micro servers and when not to use micro services and that's the discussion that's in my opinion lacking in our industry at the moment so to help this description I want to show you the alternative of modular self developments this doesn't mean that modular software developments will replace all situations where micro services are now used but I think at least in a large percentage of the cases it might be that you land somewhere in inspection between modules and micro services instead of going all the way to micro services from the get-go so why do people move to microservices a lot of times the reason you hear is that somehow their systems their monitors have become too complex to manage too complex to evolve and they want to somehow manage this complexity by chopping it up into pieces and micro-services seems like a decent way to do so some of the other reasons are about scaling a system being to being able to skill independent services and and resilience into your architecture right with market services you can have some independent philia modes etc actually if you think about it there's this complexity management question that people have is actually a cry for modularity in the skies and yes putting a network boundary in between thus forced you to make your codebase modular but it's a really really cruel tool to do so and we'll see that with other modular systems you can achieve some of the same benefits without the downsides and we'll look at scaling and resilience later as well so whatever we have a marker services system we could have something like this forgive me the examples I've been working on educational systems for a few years already so we have a user service we have assignments with students we're grading courses attendance that's all very well right and often people look at this and they say oh it's a very nice picture it looks very comprehensible and if this were a monolith then it would probably look like this right big bowl of spaghetti so like they say document code spaghetti code whatever and of course these code bases do exists in practice but it's sort of a false equivalency that's going on here I will see later that this this modulus can be structured really really nicely as well so what happens typically if people think about the messy monolith is that they start developing a system and as time goes by it becomes harder and harder to before this messy moment because you have all these implicit dependencies you fix something here and here it falls over there and you have all these different parts that have far too much knowledge of the internals of different parts so you can't really reflect there anymore people start to be afraid of touching because this all may sound familiar so you hit a brick wall in terms of costs and costs here is not just money it's also about people being afraid to touch code bases features taking longer and longer to be developed so that's something that people want to counter with microservices and yes I do think that a marker services architecture does give you a path forward to create systems with more features that skill better in terms of additional costs so this is definitely a concern that's valid however look at this gap if you start your developments with your simple monolith I mean there's essentially no cost rise you just get a team together you start coding and features to start flowing well not so much if you go the micro-services route because we all know micro services do bring a lot of additional complexity so what kind of complexity well for example if you have all these services there's this simple matter of okay how do we find its order how do they actually work together and for that of course there are all kinds of solutions we have console if Netflix Eureka XD all kinds of tools that are really cool to learn and to start using but that are also quite complex and all of this is not something that's insurmountable but yet again if you have this complexity already from starting developments it will mean that your features will start developing slower so people think ok well this this leads to some kind of service mesh technology which is sort of upcoming now sto and etc etc but also be where this can turn into a surface mess really quickly if you don't watch out now what other concerns do you have well obviously we recognize that market services communicate over a network so we're prone to all the fallacies of the network that we've all read I hope at least so the network is not reliable the network is not fast the network is not well and you know all these policies right so we need to code for this we need to cope with this into our systems and again there are tools for that like the Netflix history you can do Bill heading circuit breakers and all this cool stuff but again this has nothing to do with your domain this has nothing to do with your application so what else deployments well that's the solve problem guys just put it in docker container problem solve or is it because we could also run on basis for example you could use maybe our rockets a containers instead of docker so again here's the technology selection process going on and there are lots of cool technologies to to inspect and then if you have docker containers you somehow need to run them somewhere so you need to set up something like kubernetes or well there's there's many other tools and this is not for the faint of heart this is one of the reasons why there's such a gap that we saw between monolithic developments costs and micro services development costs and there's more of course because if we have these independent services we can have multiple versions maybe even multiple versions at once which can be really really hard to manage so you get into configuration management tooling and deployment tooling and API management tooling and yet again this is something that you as a company as a developer will have to get acquainted with it's a select have to maintain have to run I probably don't have to run it once but you have to run it four times for your development test acceptance production environments and of course there are cloud providers that's trying to help you with this and to make it easier for you but still you need to understand the underlying issues here because API management's and configuration management even with the best tooling is also conceptually hard to do it's not about all the technology is about running concurrent versions etc which released an explosion of issues that you can encounter at runtime now there's also the security angle if you go from this this monolithic web application which was fairly easy to secure you're wrong to services that interact now and do you delegate permissions or do you have a trusted sub Network or do you do any of the other best practices again lots and lots of new stuff here to learn and to apply so I'm not trying to say again that micro services are breath I'm just trying to convey what it means to do market service developments in an honest way because we've seen so many technologies and issues already now that don't have anything to do with the actual domain problem that we're solving right and yes I also think that some of these problems are really cool and challenging but the question is when should we take these problems on and why and if you look at this I mean it is this architecture is this sort of architecture like I said this had nothing to do with our domain this is more like our Couture Chur if you think about it and this is really something that you would only want to do if you really need to in my opinion and not because of school and people are trying to push it on to you so we've seen where this gap comes from when you start development in either a monolith or in the microservices way and I said previously there lots of vendors and cloud vendors that's really tried to minimize this gap and they're doing an okay job I think if you at least look only in terms of money but adopting these vendors still won't magically transform your organization into an organization and an engineering organization that really understands and lists through all these issues and challenges that with your son so really here's still something in terms of human costs in terms of knowledge that needs to be breached so what about modules how do they stack up to this micro services diction and before we do is sort of a comparison I just want to take you on a journey through module systems in different technology stacks to show you that they do solve similar problems in a way and that really adheres to the principles that we saw previously so again we have here our micro-services architecture and where previously we saw this messy monolith on the on the other side surprise surprise we can also turn this into a single application that has the exact same structure as our marker services architecture only now we don't have distributed components no we have modules we have strong module boundaries inside of this modular application and really what happens here is that we take the same design approach but instead of slapping a network in between we take a module system that helps us enforce this mountain module boundaries and that helps us make the same decisions as to where the boundaries are in other main without incurring all the complexities that we just saw previously now this gives us a third way which is I believe an intermediate between marker services all the way and this messy monolith where you hit a brick wall after maybe two three years of development so with this modular approach we still have a little of upfront cost because you need to know about the model module system and the modularity principles and you need to apply them in your stack of choice but still it's hugely usually less complex in terms of run time complexity and in terms of different problems that you're solving that are in my opinion often accidental rather really meaningful so people hear me talking about modules often and about the principles encapsulation well-defined interfaces explicit dependencies they say okay so well there's some like objects because well for example in Java you have private fields and you have public stuff and well yeah that's close that's the right way to think about it but modules live at a higher level of abstraction than classes and objects but the principles are actually very much the same so what does it look like in the current languages that we have so in Java like I said we used to have OSGi as a module system that was a third party module system which was fairly popular with a few big players like Eclipse and then other applications the server vendors etc but don't really become mainstream and as of Java 9 there is now a module system in Java itself that can help us create modules with strong encapsulation and explicit dependencies now in the JavaScript world well it's the JavaScript world right so there were like dozens of different module systems that you could choose between but lately in the es2015 standards they actually got a native module system in JavaScript as well which i think is a very good thing and we really start reading dependence the benefits from that as well what about for example C++ well we'll see that even in C++ they're already thinking about a module system that will most likely be in the C++ 20 spec and Internet you can achieve similar situations if you use NuGet packages and assemblies that are well defined if you look at what happens for example internet core you see that it's also all about creating small and modular platform so I think all these languages and all these technology stacks are moving towards a more modular feature by applying these principles and by allowing developers to apply these principles for their own applications as well so let's look at some of these module systems for example in Java we can now define modules so for a jar file we can now say this is not just a jar file but it's a module and this module exports something in this case the Athens API package so you export packages in modules in Java but we can also express that this module this jar file has a dependency for example on the students module and the courses module and this is something that the compiler will help us enforce is something that even at runtime will be available as information for a virtual system to do module resolution and to do to guys strong encapsulation because what happens in a module is that unless you export a package is strongly encapsulated so this allows you to to really hide your implementation details so any packages and any types in these packages that are not exported you can freely refactor you can change them without breaking any of the other modules the well-defined interfaces of course defined by whatever types are in your API packets that you export so only these types can be used by other modules if they have a dependency on your module and these explicit dependencies like I already said they are used by the Java module system to ensure that you have a correct set of modules that have all our dependencies set of satisfies which is a huge step up from the previous class path that we have in in Java where you just slap on a few jar files and hope for the best because there might be a jar file missing there might be a duplicate jar files and you only find out at runtime with class notes found exceptions or any of these other nasty exceptions and even the Java platform itself has been model arise using the same module system so what you see here is a small subset of the modules that are in the JDK and it already shows that this makes the JDK a little bit more understandable rather than having this big big single RTO jar file containing all tens of thousands of classes that make up the JDK and the Java library you can now see that we have these these nice little modules with their own responsibilities with our own API s and they even have these explicit relations that we can put into a chart here now looking at Java scripts like I said it is 2015 it got a model module system and there we can also see that we can export a function like the square function here and we can also have still have versions that are internal to the modules so like the function secret here is used but it's not exported and then in another JavaScript source file we can say okay I want to import for example this SQ function from my module and then we can actually use it from this disorder module now again looking at the principles here we have a form of strongly capsulation because previously everything would be in the global scope in JavaScript but now with modules this function secret is not accessible from outside of the module which is really helpful of course to protect your internals we've have some some sort of well-defined interface for this module because we exports this function SQ and nothing else and the explicit dependencies are made up by these these imports between modules in a JavaScript source files so of course when you think about if javascript is not strongly typed so if you really want to have well-defined interfaces consider using typescript but still it shows that that javascript has met great steps in terms of modular developments I've heard the result also something like CSS modules with well let's not go there and last I want to show you this is preliminary but that's still in the discussion for C++ but there's the same way of approaching modular coding there where you have in this case a module by module again we export the SQ function we have an internal secret function and rather than including header files we're going to import these modules and even much like standard i/o and we can use this query function because exporters but we cannot use this secret function because it's wrongly encapsulated and this is the well-defined interface and here's this explicit dependencies so I hope you see the pattern here these principles are starting to appear in many many technology stacks and I think we should start using them modules are everywhere and remember these principles are now applied above the level of objects with below the level of complete applications and the good thing is that we already used to be able to create these nice whiteboard pictures of our applications and we're now able to translate these into actual compiler and runtime and forced module boundaries so all these encapsulated details can now be truly encapsulated and it doesn't require any discipline anymore to enforce this no we can just rely on for example the C++ compiler or the Java compiler to help us enforce these motor motor boundaries so it's a really great way to actually translate whatever we came up with on the whiteboard into a real working piece of software so let's get back to the question because we now have seen microservices their complexities we've seen some marginal systems and how they help us in applying these modular principles so what kind of trade-offs are they and and how will you go about that so again these these were some of the main drivers for people to start adopting microservices and I would say if your reason to go to micro services is to be more modular to manage the complexity of your application then I think it's fairly safe to say that using a module system in your favorite technology stack is also a very very good alternative to this because you prevent a lot of complexity from going into your architecture but it still leaves of course the question of okay but what about scaling reasons or their resilience regions to go to market services and these are fellow reasons in some cases to go this route so what are some of the advantages of micro services over this modular application developments approach well one of the advantages that we haven't talked about yet is that if you go the microservices way then you can actually choose the best tech for each surface that you're implementing so in our example you might implement the learning material service in no GS you might implement the student service in Java and assignments in Python etc no big problem and even though this is possible you should ask yourself the question is this something that I want instead of my company is this something that my company is ready for are you ready to maintain one two three five ten different technology stacks I mean where's the limit and the question I mean it's really context dependent of course but in a lot of cases it just makes sense to go with one technology that you all know well and start using deaths so this reason while valid in some cases really depends on your context another advantage of microservices is this independence deployability of services right again here we have learning zero students and sample version effort services and we can deploy different versions on different release Cadence's from different teams and this is quite a compelling reason to go with micro services on the other hand what I see a lot of as well in practice is that this is really possible because well yes learning with your service uses the student service and the student service lucious users to learning so they can't be really independent deeply deployed they need to go together oh and assignments needs to depend on version 3 and well what you actually got here is a distributive monolith and I think that's even worse than a monolithic model arised application so even though the the promise of independent deployments really is yeah alluring it's it's kind of hard to pull off in practice and it really takes a new way of thinking about dependencies between your micro services so it's possible but a practice I see a lot of situations where this just somehow divorce into okay we'll just roll out all our five or ten or twenty services together every well whatever increment you do so related to this if you have these independent running deployments it's also that you can have independent failure so if our cyber service goes down then it doesn't necessarily have to reflect on our whole application because maybe the learning material and Student Service can still keep on serving but again this only holds if your services are truly autonomous because if we have these dependencies that we just saw in the previous life then each of these services will fall over because they rely on the failing assignment service and again this is not impossible to solve but creating truly autonomous services isn't something that you can easily do when you come from the more modest monolithic might sense you need to think about more event based integration you need to think about fall backs you need to think about all kinds of things that that's worth actually an issue in your previous situation so if you want to have this advances then your services need to be truly autonomous that's the sort of takeaway here now another one that has to do with the independent deployment is the fact that we can skill independently so what if for example our learning material service does some heavy lifting with graphics so we could for example deploy it to some very half the graphics instances in Amazon and maybe our student service this is moderately traffic so we deploy it on to medium instances and our assignment service is barely used so we just deploy it on some micro instance this is a really nice way of scaling if you have micro services so if you have this issue if you have different components that have truly different scaling needs then yes extracting them into a micro service makes total sense however it's not as if you cannot scale a a modular mallika application only the fact there is that you skill uniformly so a lot of model of applications that we develop we just deploy them to Amazon as well with multiple instances as well but you have the whole model our code base running on each instance and in our case most services don't really have these really different scaling profiles that that show previously so this works with works pretty well when we just put a load balancer in front and have these model application skills in full so again this is not an either/or it's just a trade-off if you look at some of the advantages of modular applications of modular monolithic applications then yes we of course have something that's easy to deploy because once we've built the application and all the modules have come together we have a single deployment units that we can deploy what do we do that on the cloud or bare metal doesn't really matter but this is something that we can due in much the same way that we did previously as well another advantage of modules is that it's really really helpful to have compiler support if you want to refactor across module boundaries so what usually happens if you go to micro services routes is that you think really really really hard up front about the service boundaries and then once it's in place and in production and the poise well you better have a very good reason to change the emotional boundaries because it's a lot of hard work right it's couldn't coordinating between different teams different code bases difference it's it's it's hard and how hard this is proven by this picture I took from a uber presentation and it's interesting what happened there is they they started from a monolithic situation where in 2014 they said okay we're going to do services and then in somewhere 2016 they ended up with 1,800 micro services well I mean it's a ride-sharing app I don't think there are eighteen hundred independent business functionalities and that's also something that was acknowledged by by met already and one of the you boletes who gave this presentation and he said okay so what what really happened here is that teams started creating services and then they needed another service which was already sort of in place but didn't really match the requirements of the other team and then they had two choices either they had to go negotiate with the other team to change the other surface and then to wait until it was finished and prioritize and then just play politics at least or they could just sort of clone the service tweak and match it to their own requirements and deploy it and running themselves and well guess what happens people take the path of these resistance and that's how you end up with 1,800 micro services which I don't really think is something that you should try for now another advantage of the modular application is that we're talking about strongly types in process communication rather than the weekly or Jason type interaction between network applications with the benefits excuse me of having of course virtually no or no or lesser ization overhead or network latency and really there's a lot of boilerplate goes going on in many of the micro services applications that I've seen you prevent that by going the modular routes and have you ever tried serializing a function if you do sort of functional programming it's really hard so doing marker surfaces also sort of constraints the types of api's that you have between the implementations in your system so if you do go the micro surface routes really consider instead of doing sort of anti pressed also to explore for example something like Avril or protocol workers to have a more tooling supported way of evolution and the communication in your AP is the other thing here is that strongly types in process communication also entails synchronous communication and if you have truly autonomous micro services then you'll you'll find out that lots of lots of work that's happening inside of your application services will become async and fortunately we have lots of land very nice libraries to help us with that like Eric's Java or all of the other reactive first stuff but still it's it's it's harder to reason about and maintain then the more synchronous way of interaction that you can do in a modular model if now that doesn't mean that everything has to be synchronous ID of a model application I mean you can still apply eventual consistency for example between different parts if that fits your domain if that fits your problem but it's a choice that you can make and it's not something that's forced upon you by the physical architecture that you've chosen in any case what are you doing modular developments or micro services developments it's still always a good idea to partition your data and with that I mean you often see that people advocates that marker services shoot on their data and I think the same applies to modules inside of a modular application a module should be responsible for a part of the data and it shouldn't be sharing this internal schema with other modules so this is something that that can go both ways now having these nice explicit dependencies between the modules in our modular application means that we have less possibilities for real time values because we can statically check that our set of modules is actually correct and it's actually something that will work as an application whereas if we have the dynamic service discovery in our service mesh or service mess then we do have the issue of services not being able to be to reset run time and you have just different failure modes going on there so I think it's time to wrap up and and sort of make up the balance and I wouldn't do this by looking at this tweet and there's this guy who watched a presentation from Joan Osborne air at live bands was a really great presentation about reactive micro services and he had this sort of Epiphany right he said okay Wow moving from a monolithic to a micro services architecture is like a bit like going from classical to quantum mechanics finally something that matches reality and to which I say ok well yeah we had this this quantum well as if the etc that was discovered by Einstein which really taught us that at the speed of light everything changes but the question should ask yourself is are you really at the speed of light are you really at the limit of everything because for all the rest we still have our Newton who just gives us classical mechanics to say ok chill out the Apple still doesn't fall far from the tree so what we're doing here is you don't want to solve problems that you don't have you don't want to bring additional problems into your architecture if you don't need to and this is really something that has to do with skill and what kind of organization are you you're most likely not a uber or Netflix at least most systems that I built are not at the scale and I think if we're looking at this honestly it's really a long deal of systems and organizations that do not have these immense scaling needs and these immense problems that uber or Netflix face so be realistic about your own situation and about your needs and try to figure out whether you're doing micro services just for the management and the modularity aspect where if you truly need some of the operational aspects as well because I think well like the 80% of us are already somewhere there and I'm going to leave you with some wise words from Socrates as well find it on Twitter and he said to us okay like you know company this is an ancient Greek word meaning more containers than customers right so this is really something that I think happens in their industry we start jumping on new technology and start using it because it's cool but in the end you should only use it because you need it and you need to find out why you need it when you need it and how you need it so what do we do you solve the problems you do have in the the simplest possible way as far as I'm concerned and that means in this case I think you owe it to yourself to at least read up on whatever is happening in your favorite technology stack in terms of modular developments so you have this alternative available to you if you want to and besides it's never bad to know about for example strong encapsulation well-defined interfaces explicit dependencies these are all timeless and technology agnostic principles that can help you create better software create more maintainable software and extensible software so what will be my advice to you I would say from the start design your system as if it were a micro-services system so do think about the boundaries in your domain do make nicely decomposed components in your system but don't start building them is microservices yet pick your favorite technology stack that has the the principles of modularity in terms of a module system and start building the system as modules and if you need some of the other benefits that we talked about from marco services you can always yank out one of these pieces and start using them later as an independent service because you've already done the hard part which is decomposing your domain into these nice modules with these same module boundaries and in the beginning if you do this in a modular application you still have some leeway to refactor across these modular boundaries like a talked about and then once your confidence that you're there and then you need scaling needs that you need the imprint failure modes for the independent deployments for some part of your service then you can just put and pull out the service and start treating it as a micro service the question also is shoot a service always be micro if you have this modular approach maybe you can have more coarse-grained services as well and this also decreases of course your operational burden and don't worry I mean you can still do all the burst words you can do react safe no sequel Klauss DevOps domain driven design I know these are often sold as a package deal with micro service but really that doesn't have to be the way you can just as well apply these principles in a modular monolithic application so if there's one thing that you take away from this talk I hope it is this picture where we can easily see that we don't want to end up in this messy monolith situation I fully admit that has happens to a lot of us to me as well in the past and that's something that we just don't want right but solving this by fully going all-in on micro services is really something that isn't just up to you as a technologist because it brings so much other costs with it as well and in that sense you owe it to yourself to also explore the modular application alternative and I hope you've had enough information to start looking into that now so with that I would like to thank you all for attending this talk if you really and like to read more about this then I encourage you if you're in Java space to go to Java molarity that come really far more info about the book I've written with Paul Barker the bitly link I've shown here is an O'Reilly article that I wrote last year which details all the arguments that we talked about here as well so if you want to share that with a colleague then please do so and I also have some Pluralsight content if you're interested in that check it out and if you don't have a subscription come up to me I'll give you a free month and with that if you have any questions feel free to come up after the talk and I'll be here all day and tomorrow as well and I'd really like to chat with you about your thoughts about modules or marker services so thank you [Applause]

Channel: Devoxx

Views: 6,137

Rating: 5 out of 5

Keywords: DVXPL18

Id: AJW2FAJGgVw

Length: 47min 26sec (2846 seconds)

Published: Sun Jul 15 2018