Join Now!   |   About Us   |   Contact   |   Sign In
Community Search
Raleigh
Group HomeGroup Home Blog Home Group Blogs
Search all posts for:   

 

View all (8) posts »
 

How can I be successful implementing Microservices?

Posted By Phil Helm, Wednesday, August 17, 2016

This blog post is one in a series that will give you some insight into the full day training class (Microservices Solution Architectures) I will be teaching at the ITARC Austin on October 6th, 2016

A better question may be "If I can't/don't change , am I going to create business value?" In my opinion, the greater number of changes you can make around the adoption of microservices the greater chance of success with the implementation. 

In my opinion, the best chances for success will rely on the following:

1. Adopting a cloud-first development strategy

The ability to independently build, deploy and support microservices means your existing monolith may turn into dozens, if not hundreds, of vertical business capability slices. Scaling this idea in your datacenter is most likely not going to be successful - unless you have build your very own AWS or Azure from the ground up. In my experience, the cost alone to implement in a proprietary datacenter would be enough to steer away. 

2. Implementing DevOps (or at least, continuous delivery)

How will you truly get the "speed to market" benefits purported by microservices if you can only push code to production every three to six months? The market moves very quickly, and the ability to deliver new and enhanced capabilities at a rapid pace will help differentiate your business. 

3. Organizing around small independent teams

This has to do with dependencies and coupling. If a single large team owns all of the microservices/capabilities, there will inherently be dependencies between capabilities as well as deployments (think Conway's Law). If you want to deliver enhancements to your shopping cart, but it's dependent on (or is a dependency for) your user profile or payment system, your push to production may have to wait to make sure you don't break other capabilities.

4. Adopting a more flexible SDLC

I almost put the word "agile" here, but that is an overused term. I don't know a single engineer or architect that loves waterfall. Your microservices won't love it either. As microservices are small and independent, so should your delivery process be. Is your business going to want to wait six months to review what you have done? What if they don't like it?

5. Implementing a container strategy

Most likely, your microservices will need to be in containers. The speed and efficiency at which containers deploy and exist is far superior to virtual machines.. and chances are, you will need to share resources. What if your microservice needs to live on the same virtual machine as other entities? Now you have a dependency on the specifics of the environment. Alternatively, if a single microservice lives on a virtual machine, is it going to utilize the CPU, disk, memory efficiently?

6. Adopting domain-driven design patterns

Whether you are decomposing a monolith or working with a business capabilites map, the ability to decouple your functions from one another and create a bounded context around each one will make your microservices deploy quicker. Designing your microservices in such a way that they align with business capabilities allows for independent management, versioning, maintenance and enhancement. 

7. Coming to terms with eventual consistency

Microservices are, by definition, vertical slices of capability that extend all the way to the data layer. However, this means that microservice A may have data that microservice B requires. Even if microservice B has the data, it may be stale as each service is not working on the same copy of data as they are independent. Designing your system in such a way that allows for user data to be eventually consistent breaks the need for hard requirements on things like dependencies and transactions.

8. Preparing for increased failover/monitoring/logging capabilities

How successful are you today in handling disaster recovery for your monolith? How easy is it to debug a problem in production? What happens to your performance at various peak hours? Any answers here would need to change considerably with microservices. You may need to monitor many capabilities/microservices at once. You may need to track a user flow through multiple services. A single microservice (or potentially multiples) may be at fault for performance issues. The infrastructure and process around support is vital. 

 

The ability for organizations to change not only the technology but the design, process and understanding will be the most successful with microservices.

This post has not been tagged.

Share |
Permalink | Comments (0)
 
more Calendar

The upcoming calendar is currently empty.

Click here to view past events and photos »

Featured Members
Madhukar RajagopalIndustry Expert

Association Management Software Powered by YourMembership  ::  Legal