How Microservices Are Going to Transform Software Development Large software projects are better developed in modules. Those modules will not just have an impact on your software but on your team. In hopes of sustainable software development, Microservices seem to become the first choice for large teams. In comparison to small teams, large teams usually are harder to manage. They have a large appetite for communication and complex structures. This is a constant due to organisational growth. Melvin Conway had observed that how organizations were structured would have a strong impact on any systems they created. A study by Harvard Business School study found that the often co-located, focused product teams created software that tended more towards tightly-coupled, monolithic codebases. Whereas the open source projects resulted in more modular, decomposed code bases. To clarify, a monolithic application is usually built as a single unit and hard to reuse. Enterprise Applications are often built in three main components: a client-side user interface a database, and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and
populate HTML views to be sent to the browser. This server-side application is a monolith a single logical executable. Any changes to the system involve building and deploying a new version of the server-side application. To put it in Conway’s words, an organisation building an enterprise platform like this one will most likely be separated in three teams and will represent the organisational structure. It is possible to have a more detailed split within each and every block but the project will still be represented by 3 different components. If you turn that around one could easily say lets build our structure after our software choice. So instead of seeing it as a burden see it as a chance. In fact, team structure and architecture affect each other. So can we solve the problems of complex project structures with a different software architecture? I found this diagram by Manu Cornet on Bonkers World that I thought was a fair representation of Conway's Law.
If we were to go back to our Enterprise Application structure. The time to set up a project like that takes weeks until everyone understands the interfaces and team coordination. It seems rather daunting for someone out of scope, right? So what if we open our development structure to a functional level with teams lead by one manager? Take a this e-commerce example with Search, Ordering, and Registration. Every team obtains a product owner who is able to independently implement new functionality for its domain.
Architecture Admittedly, it isn’t that easy. There are still interfaces and coordinating personal involved. Assume your search result points to a product which should go into your cart. The objectinterface should still be coordinated. Those interfaces are in flux in make the need for coordination necessary. This seems confusing since tightly coupled packages slow down development. And that is not the topic of this post.
Alongside with the functional architecture your hardware has to comply, too. Often systems have to be coordinated due to releases that might not work well together. Which means that you have to commit to a certain stack which takes a considerably amount of time and might slow you down in the long run. And by long run I mean that you might not be able to deploy as many new updates as you want. Which in turn will slow your software progress down. You see that circle?
Minimize dependencies To minimise dependencies, your architecture and your components have to be in alignment with your technology stack. The latter should be very flexible. An example would be to use independent software together with virtual machines in order to let teams evolve independently. In context to virtual machines, today’s package managers establish a development environment where teams use software written by other creative minds and still are able to make use of their own efficient stack. This enables components to be develop independently from other components.
Keep your components simple Simplicity seems to win more frequent than monolithic, inflexible solutions. With simpler components you reduce the amount of testing and bugs. This way implementations of new features become even simpler. This approach is called microservices.
And with everything new, definitions vary. A common ground is the independent aspect for development and deployment of microservices. It seems that, relatively speaking, the independent deployment approach has an even greater impact on this approach than our discussed technology stack. This means that teams don’t have to coordinate development cycles and deployment dates. More importantly, it enables an agile development environment. With this in mind and a faster development pace of deployment and customer feedback, teams might be able to work on several packages/microservices.
I call it a system of systems with several micorservices in parallel. Ordering processes being development with several services but only by one team. It is still one part of an organisational structure with a very independent development ability. When selecting an interface for a service, it is useful to think first about how services interact. There are a variety of interactions which can be categorized as one-to-one or one-to-many and synchronous and asynchronous using multiple service instances.
The communication can be established via REST, or messaging (e.g. DDP for Meteor). Which in turn will have an impact your microservice’s logic. Those service philosophies are dependent on whether data has to be presented on several layers for your application. Sometimes it is necessary to analyse data and or render it raw to the client.
Your advantage Ultimately, microservices are equivalent to modules and or packages. A major characteristic however, the way communication has to be established between services differs from modules. REST and, or messages can only work when interfaces are in place. With this in mind, architecture research deals with improvements and covers maintenance as well as
development. Research is geared towards the easy of changing and adapting features alongside your stack. A smart IDE might help to change code within a monolithic approach but will cause more effort into adaptation for a service. The questions is, how many times do you change your interface and how many interfaces are actually affected by this modification?
Micorservices are designed to endure longer periods of time and to help make development easier. Assume you want to change your communication from REST to messaging with out chasing your interface? The only important aspect here is to change your service and deploy it again. Again, it is independent from your apps environment. Assume you want to change your search to make it more effective. You choose to go with Elastic Search. Your filter methods are still the same and your results still expect the same data, all you have to do is the way you communicate with another middleware. But it solely affects your microscervice logic. Those services could even complement a monolithic app and help to transfer from one feature to another.
Micorservices are a blessing when it comes to supersede a legacy system. Otherwise, it is a very expensive and time consuming endeavour for your team or company. It’s just more sustainable.
Who coins and develops with microservices Amazon, Netflix, Facebook, Twitter.. Take Netflix, it is build on an Amazon clouds service. Micorservices are so important to them that they developed their own technological infrastructure for them. The whole topic seems to be hyped a lot because many software companies seem to face the same problems concerning time to market and ease of alterations.
With new ways to develop apps you have to understand the implications, too. With a fair amount of services you will face a automation “nightmare�. Its not really a nightmare but you have to understand it in the first place. Microservices need monitoring and that might include several levels of your apps logic. To guarantee your teams independence you might
need to deploy DevOps which take on business related matters. Microservices are distributed systems and require you to plug all of it together so it makes sense for you application. On the other hand, decentralised systems can bypass information in case of emergencies. That goes for microservices as well.
Once established, micorservices can help to build several apps in a shorter amount of time using established code bases. Following Netflix research and their approach has helped me a lot in the way I develop my applications. Applications seem to scale faster and more economical since only one service is affected, at a time. Communication seems to become easier due to a lower extend of common ground.
Microservices are capable to solve fundamental problems in software development. It makes transfer from legacy code easier and introduces a more agile thinking. It guides your company to a less dependent code basis and makes your development more sustainable.
And just what could I do for you? Well, let’s find out. You can get in touch with me through the following mediums. Let’s talk coding and all that it could deliver for your project, whatever that may be.
Email - michel.herszak@gmail.com Twitter - @MHerszak (twitter.com/MHerszak) Want to know even more about the way in which I work? You can check me out over on my website, right here.
Further resources: - https://www.nginx.com/blog/building-microservices-inter-process-communication/ - http://thenewstack.io/microservices-four-essential-checklists-getting-started/