You may went through this multiple times: Why should I consider a microservices architecture? It has been written and spoken a lot in recent years about Microservice Oriented Architecture (MOA). I’m not going to describe it, because there is enough about this in internet and books (highly recommend Building Microservices 2015 from O’Reilly). Here I will like to discuss which project should consider implementing Microservice Oriented Architecture.
Compared to monolithic systems, microservices:
- are easier to scale;
- are easy to incorporate new technology;
- are easier to manage and develop in multi-team company;
- provide good development patterns;
- difficult to start;
- more complex to setup. They require distributed system which can be complex and hard to manage (though if you need a distributed setup this is the way to go);
- require more tooling;
- require experienced team to do it correctly (microservices increase amount of infrastructure and operations management);
- Seven micro-services architecture advantages;
- Quora: What are some disadvantages of a microservice architecture?;
The whole concept of service oriented architecture is old, but the first big implementation and promotion of MSA has sprung up around 2005 (, ). It took more then 20 years of software engineering to find the first big implementation of this pattern (I’m assuming here that large scale software engineering started in mid 80’) and additional 10 years to find out how to do it correctly.
Antipaterns when approaching MOA
When going to microservice oriented architecture you can easily trap into common antipatterns:
- Nanoservices. Nanoservice is an Anti-pattern where a service is too fine grained. Nanoservice is a service whose overhead (communications, maintenance etc.) out-weights its utility. Few important downsides of nanoservices: performance issues (eg: network round-trips, serialization cycles), increased maintenance cost, dependency spaghetti (mixing and splitting logic to much between services). The first mark of nanoservice is when the amount of infrastructure and networking code of a service takes over the amount of business code.
- Don’t allow business context to be mixed across many services. Keep Bounded Context.
- Common practice in a microservices architecture is to segment services and their corresponding data management systems. Since each database is segmented to support the service, management of the databases and its data becomes much more difficult.
- Moving communication to a storage layer. If you delegate a part of communication between microservice then they will not be independent any more.
- Integrate to late. Imagine that a web page is served through multiple services. Each response must be integrated and presented in one view. All parts of this view must be consistent. What’s even more harder: they might interact between each other and depend on single style definition.
SOA (Service Oriented Architecture) to unleash!
Do you remember what software architects were advocating in early 2000s? SOA! Please recall What is service-oriented architecture?. The basic SOA concept from early 2000s provides simply and good system design which can easily scale to microservices and doesn’t brings it’s obstacles from the very beginning.
Should I start with Microservices?
Don’t follow the hype. What’s good for a big companies might not be good for you. As a general principle you should consider pros and cons, counting: project size, system complexity, team size and business perspective . Well managed monolith system are not that bad for small projects. SOA applications with well managed master service and multiple specialized services are more then enough for most of the projects you can think about.
> Stack Overflow site is non-microservices-based-platform, with 4 milion registered users, is working on just 11 web servers. Compilation of all platform (.NET) takes 10 seconds. 110k lines of code. Well designed code by Joel Spolsky(tm)
That being said, whenever doing a long term project you should always think about MOA. If you don’t have scale requirements now your team is small - try to think that you will have them in one month. Don’t over-engineer, but follow the well thought patterns and SOA.
|||Why should I consider a microservices architecture? https://technologybeacon.wordpress.com/2016/03/24/why-should-i-consider-a-microservices-architecture/|
|||Martin Fowler nicely describes the concept and history of microservices at http://martinfowler.com/articles/microservices.html#footnote-etymology|
|||Wikipedia: Microservices - https://en.wikipedia.org/wiki/Microservices|
|||Should you build microservices from day 1?|
Every software developer and an application designer is facing over-engineering. Instead of providing a great user experience, over-engineered features frequently are not useful and are missing the deadlines.
What is a useful application?
When doing software development I like to think that users want crazy applications and complex solution. I tend to believe that the more robust and generic applications is the more useful it is for users. Thankfully this is utterly wrong.
Users are expecting a trust. They want to be sure that an application is working as it promises, provides correct results and adds some value. Eventually, they want to feel a need for it and have a good experience while using it (smoothness and intuitiveness). Typical user doesn’t care if the application do 100 of extra things, or if the application is ready for unknown features.
With a solid trust one can develop any need for users!
How we can develop a trust and a need?
Below I’m listing few concepts which are helpful when designing a useful application.
- Design for trust
- Follow the Airbnb case study. The application aim is to sell a service which is impossible from the investors point of view: customers private space to host strangers. Stranger = danger, right? They had to develop trust so people would like to offer a hosting place. They achieved it by creating a warm, clear, straight-forward and trusted design. Right design can overcome adoption difficulties.
- Trust challenge
- You need to find out when people will trust your application. What features will make your application that people will not be afraid of using it?
- Well designed reputation system
- Introducing first
- Very important. If a user is not confident and curious about the application he would be more likely to leave it.
- Unique data or places to access
- Does your system provides something unique or curious?
- Promise of human connection
- If users can build a connections between themselves the system is likely to be used more often. Building meaningful connections is more important then building empty transactions.
Case study - collaborative consumption
From Wikipedia: Collaborative consumption as a phenomenon is a class of economic arrangements in which participants share access to products or services, rather than having individual ownership.
Today we are living in a hyper-connected world. We are bombarded by tons of information every day. And we are producing and propagating information.
The Guardian article The rise of collaborative consumption and the experience economy outlines how the sharing economy is building the big global networks. Each of this global businesses relies on the observation that experience and time are the most precious commodities we have, and that consequently ownership is becoming more irrelevant than ever before.
Let’s think how trust is important in this businesses? How quickly they can fall if they will loos the trust? Or if a new player will appear on the same market with better trust and reputation system?
Case study - don’t cross the limits
Lately, we were designing a model for the next feature - a lineup reports repository. The business use case is to consume this reports from company partners and display them in our application UI providing very simple filtering utilities. The requirement says: Consider that our application is a repository of objects. We must display them in our UI as it is given. We got several reports, we learned them and started modeling. In the first round we wanted to integrate data from this reports with our domain by normalizing them. Thus we introduced several mappings - tables which will be used to translate their nomenclature to our. Besides, we needed to provide a fallback solutions. I wanted to be consistent across all our application data. Problem was that each report provider has his own way for naming things. The core concept of data delivered by each provider is the same, however it varies in details. Nevertheless we need to display them in the same UI.
It turns out that our initial work was far ahead business expectations. We tried oversee the further integrations which were out of requirements and user didn’t care about them. And of course we have a deadline. We over engineered. We started the second round of modeling with a new goals:
- Focus on storing reports in order to quickly handle new providers.
- Easily process latest reports data from providers in order to present them to customers in our UI.
We redefined the model by finding out what is the common base in all reports and what we have to unify to provide required user experience. We removed almost all our mapping tables and hacks. We didn’t need fallback solutions. Eventually we made a design which only normalized the critical part of reports and store the rest as it is given. We decrease the expected development time by 50%. The business team was happy. We will use the saved time in the future if we will have a new requirements about analytic we wanted to foresee. Now we are happy that we will easily deliver the solution before the deadline and satisfy our customers who just want to see the reports.