Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software archite...
For further actions, you may consider blocking this person and/or reporting abuse
Nice introduction to some of the technologies and terminology Sara!
I always find myself returning to James Lewis & Martin Fowler's article on microservices to refresh my understanding of why and how this architectural style can or indeed should be applied, as sometimes it should not! martinfowler.com/articles/microser...
I would also caution against joining a technology cargo cult based on 'because Netflix, or Soundcloud do it this way', primarily because we are not (and are unlikely to ever be) Netflix. Our challenges are different and need to be understood properly, using local knowledge from the business and the technology teams, before embarking on major structural shift - as you put it:
This will be a great deal for the entire company so you should discuss it seriously.If readers have time (40 hours of videos!), I highly recommend this on line course from Udi Dahan on distributed system design, which is currently free (normally several thousand $$): particular.net/adsd to cover the wider aspects.
That said - my business are part way through a transition towards microservices, and while we are not getting it completely right (hey, it's new, we're human), it's been very refreshing to experiment with new ways or working, decentralizing design authority / autonomy and modern cloud native technology. In our case a primary driver was decoupling the large team into smaller more autonomous squads (yes, we are trying out that stuff too!) with fewer barriers to deployment and more robust operational processes to be able to move faster in our market. Technology and process/methodology choices were taken based on this need, not because they looked cool on a CV :)
I completely agree with you Phil.
Usually, there are a lot of variations of microservice architecture out there. Teams are trying to create something that they think will be the most suitable solution for them. A few years ago, when we were starting with microservices we tended to create a microservice for each entity in the system and one microservice which was doing all the business logic and orchestration of other services. Quickly that service became sort of a monolith.
We realized that this is a bad design so after that we took a step back and started developing microservices that will solve certain domain problems like Continuous Integration, User management, etc. Now we have fewer microservices but still are able to organize our teams in multiple squads and spend very little time on maintenance on our infrastructure.
I guess the crucial thing is to find the right time and the extent to which embrace the microservice architecture.
Thank you for the additional resources :)
If you are bulding independent functionality with broadly different capabilities then deploying these capabilities as separate services makes sense. That is you need to organise Microservices based on what they do.
There is a danger that they can become based around objects in the domain. Each Microservice should have it's own resources such as databases. The idea is that they don't share common databases. To create separate services around individual domain objects will only make things less scalable.
My own approach has been a general purpose platform which is runtime configurable, much like a database server can have a runtime defined schema. We have made the platform application totally configurable from data objects to user interface. I've extended this all the way to the REST interfaces. This way any node in the cluster can service any call.
No worries about scaling up, just add more nodes to the cluster. Because any node services any call there are no service choke points. Because configuration is runtime there are no deployments. Business rules are adaptable, not burnt into the binary.
The same technology runs equally well on a single box and a distributed cluster. It also means that rather than huge IT teams you could start giving managers ownership and control over their own processes and applications.
youtube.com/watch?v=uwZj4XF6zic
Interesting approach Peter, sounds catchy.
What would be the boundaries of the problem this kind of platform would solve? Is it everything you could imagine, or the focus will still be in certain areas like software delivery automation, IoT, finances etc.?
In my opinion, a general-purpose platform would give more flexibility but at the same time it would require strict knowledge and expertise to define and represent the problem to be solved.
If you consider a SaaS that abstracts a great amount of complexity with delivering web applications or microservices on Kubernetes, for somebody to be able to do the same in a general-purpose platform would require a lot of time and expertise to make it work.
Usually, there are cases when somebody likes more flexibility and cases where somebody likes to focus primarily on building the business and leave other aspects to be solved by competent SaaS.
The situation with this project is complicated. It is not an offering you can buy or something you can find in a public open source repo, at least not yet.
We don't yet have a system capable of creating fully rich business applications. There are some missing components to be considered a full application development platform, but it is being used to deliver multiple analytics applications. The trajectory is toward a business application development environment.
My experience so far is that you need designers with a good understanding of data and UI design. These designers don't need to know how to code, but they do need to know about databases, data transformations, how to set up visualizations and navigation. Once configured it has a elegant UI for the users.
Basically there are three tiers. There are the developers who maintain the core platform infrastructure. Then there are designers who configure applications who are not coders but who are skilled with the tool. Then there are users who simply use the finished applications.
I'm not keen to claim this a totally generic 'application development' system because I'm fully aware of the folly of such claims. It aims at business systems which work with textual data and business processes communicating with other systems and partners.
I know this might sound 'too good to be true', but it is founded on some hard won experience and good ideas from many people over several years. Hopefully one day I will be able to show everyone.
This sounds like the 'scaled monolith' pattern, with the code/logic to handle any events available but not always used (configuration applies constraints) across a compute platform? The challenge (as expressed by @sarafian ) is in disciplined deployment and operational expertise, promoting configuration and config management (CMDB) to a first class citizen of the ecosystem (as it should be!).
Udi Dahan (course linked from my earlier comment), and others suggest that SOA (and by extension microservices) allow focused solutions to business problems to be created directly in custom code, rather than attempting to predict the future and develop a configuration-driven 'toolbox of capabilities' that makes others (typically consultants - see SAP!) responsible for understanding and solving business problems. I guess it depends what you are selling - the toolbox or the business outcomes ;)
Thank you Phil (@phlash909 ). I personally find this aspect the most under considered in any topic in IT and only Fowler is one of the few people actually discussing it as part of the "solution". And the most funny thing is that these questions are primarily for the business people (set the business goals) and they refuse to engage and just consider it a technical "solution". But no solution exists to an undefined problem and therefore undefined expectations.
Exhaustive article and will done for the effort. Not sure what the purpose was. The only one I see is to do some sort of indexing of what is available. Don't get me wrong, it helps a lot.
Anyhow as a high level topic missed is how to make the services speak with each other. Synchronous or asynchronous probably with RPC.
Another topic is the versioning and the rollout. In my opinion if this is not understood or the culture can't deal with it, then microservices are wrong.
Too extend the above, the single most important topic to discuss is culture compatibility and not only with the development team. From what are the goals to what to expect and governance and more. Essentially how the entire organisation operates.
With regards to data, this is something almost never discussed. Most people consider a microservice as a reusable instance for every domain. But it shouldn't be like that. I group my services around one domain and those micro-services become internals along with their databases, which means copying databases. Kind of depends on the purpose.
I agree, these are very important topics. But, they are very wide and deserve separate articles written for them. We could elaborate on them in some of our next articles.
Yes but so did the others you mentioned. I'm not criticizing you, just pointing gaps in what I think was an exercise post that resulted in some indexing of resources on the topic. Well done btw
I have read a number of articles on microservices and this has been by far the most simply explained. Would like to have an idea of what domain model designs would be like in this scenario. Eg I have a microservice that manages warehouses and inventory, then another that manages purchasing of goods that will be stored in these warehouses, will I have to replicate the domain model and database table for warehouses in both applications? Because if the purchasing microservice pulls its warehouse list form an API coming from the warehouse service, then purchasing can never happen if the warehouse microservice has an issue
This is a topic that is discussed a lot with many different opinions involved.
In general, sharing a database between microservices is not a best practice because you can quickly lose control over who is doing what with the database. Database update of one microservice could potentially corrupt other microservice and you will end up with a broken system.
Another thing to consider is that microservices should do more than CRUD operations, otherwise you should consider merging multiple services that solve one domain problem in one. So if you need
data for inventory I guess there would be additional logic that you wouldn’t like to duplicate in the purchasing microservice.
When applying domain-driven development, the domain is the holy grail. You group system functionalities based on domain problems they are solving. Reliable communication between microservices is something that should be solved with different strategies like a circuit breaker, events, queues, error handling, etc.
Micro-services are nice. Monoliths can be nice, too. Now, I think the real challenge is to decompose your problem domain in order to have independent modules, micro-service or not.
An architecture style won't do that for you. Only your brain (or the collective brain of the team).
Muy buena explicación, gracias :D
Gracias a ti también :D
Thank you, this is very informative and brilliantly written!
Thank you so much Ali :)
Will gRPC replaces REST?
gRPC: Is it replaces RESTful webservices?
If you want to know what is gRPC and how to implement Microservices using gRPC framework, then check out following playlist:
gRPC Java Tutorial: youtube.com/playlist?list=PL-OjXpI...