Why Microservices and continuous deployment (delivery) is win / win

Microservices is nothing new but has become a standard in many systems during the last years. There have been trends in architectures some engineers use them as a silver-bullet. They used the Architectures even if not required by system nor requirements. DNA, 3-teir, SOA, DDD, CQRS, Onion architecture and so on. Is Microservices just a trend that will destroy systems because people will use it as a silver bullet? Maybe! The future will tell. Let’s investigate why microservices will be a good benefit for the continuous delivery approach.

 

As most of you know by now, is that continuous delivery (CD) is an approach to deliver functionality in a smooth and almost automatic throughput. CD is an extension to Continuous Integration (CI) that are the configuration that tells you something will happen as soon you check in your code in to your source control. It can run tests, if it fails it will not publish the system or do something else that’s important four you and your business. I use CI to tell the build server to build my system, run some test and send it to production with continuous deployment.

The different between Continuous Deployment and Delivery is just that deployment automatically deploy your code when delivery just give you a package that you can manually deploy

softhouse_CD_loop2_new3

As always it is requiring discipline in your mindset as well in your code. It will be forced since you release everything in to production. So why is microservices a win/win with this approach?

The opposite to microservices architecture is the monolithic systems, it’s a system with a server where all your business capabilities are grouped into one big product. With continuous deployment and delivery, we just need to release lots of code and run lots of tests, this can be tricky for the benefit of a smooth delivery. Maybe you need to migrate your database, change many contracts and increase a big and complex domain model every time you will push some new feature to your CI/CD configuration. You can save you lot of problem with feature toggling but you still need to release the whole system. This is when the micoservice architecture will save you from lots of headache. Micorservices are like small systems with their own architecture, components and tools needed for your business capabilities. I often explain them as CRUD services for different business areas like a product service, invoice service, order service, authentication service and so on. I also like to refer to them as a SOLID principle architecture on an architectural level rather than just on the code level.

Microservices shall have single responsibility (S) for its business area, it shall be designed open for extension (O), like version controlled REST APIs. A new version extends its functions. With backward compatibility you will have a subtypes of the API (L) and so on.

scaling_agile_model1scaling_agile_model1

Microservices allows you to deploy specific services instead of the whole application when minor changes is applied. You simply deploy that service and only that service code. If you use containers like Windows Containers or Docker you have even better CD benefits though you don’t need to replace any files on the already running service, you just deploy a new container and can easy activate that one as soon you feel comfortable doing so. With other tools like Azure service fabrics you will get even more nice supporting tools for crashes, rollbacks for versions if one deploys fails etc…

Microservcies also benefit from less merge problems despite the fact that it is simple to use different microservices within your team. Discipline implementation of feature toggle minimize the feature branches so you really go Lean with the whole architecture and spend less time on configuration management.
Summary:
– Less code within the codebase

– Less problem with merges if using feature toggling, version handling instead of     branches

– Less problem with deploys though you now deploy the whole system, just a   small part of it

– You will have benefits regarding scaling each heavily loaded service instead of scale up the whole system

And lots more… But remember, this is not another silver bullet, it’s just a bullet of many

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @Johannormen

 

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s