30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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 :)
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 :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 :)