Intro to the subject

I have chosen this subject as my research but one the main question is, why? I’ll try to capture that in this blog post.

Microservices is one of the controversial and hot topics around software design. In this research, I will be looking at the definition of Microservices and how it is different to Monolithic design, when you should go with Microservices architecture and what are the challenges (technical and non-technical) around it.

What are Microservices anyway?

Just like Service-Oriented Architecture (SOA) era, a lot of people jump on the bleeding-edge of the technology without understanding what it really is. Then by comparing and contrasting the new thing to what they already know, they come to think that the new concept like SoA or Microservices is what they know and what they have been doing all along! This is a form of Confirmation Bias, which is a separate – although related – topic.

According to Martin Fowler, Microservices are a architectural style that has specific characteristics:

  • Organized around a Business Capability
  • Decentralized Governance
  • Decentralized Data management
  • Infrastructure Automation
  • Design for failure

We’ll go over each of the characteristics in a separate post.

 

 

 

From Monolith to Microservices: pitfalls and challenges

Project Problem Domain

Microservices design now have become more prevalent. You can run them on the premises, you can run them in the cloud, and you can run them in edge-computing, but should you? Big corporations like Amazon, Netflix and Uber have been doing Microservices style architecture to varying degrees and have contributed to their popularity in the recent years, but as with any other architectural style and pattern, challenges lie ahead.

Background

I have been working as a software developer for twenty odd years and I have seen ‘new’ technologies come and go. It is very easy – and tempting – for a software developer to jump on the latest shiny technology (living on the bleeding edge) where as there are numerous other concerns that need to be taken into account when dealing with such technologies, and not all of these challenges are technical.

Project Aim

When dealing with Microservices, there are organizational, design and technical challenges ahead. Concerns vary from concepts such as organizational structure, domain decomposition techniques and service boundaries, to a more technical-oriented aspects such as deployment, security and UI integration patterns. This project aims to have a better understanding of the said challenges and research some mitigating strategies on how to deal with them.

Deliverables and Outcomes

The goal is to have a set of challenges identified and suggest a strategy that’d be useful for when moving towards a micro services type architecture. The deliverables will be reflected in the weekly blog post and status reports.

Resources

  • Software Development Journals (e.g. Journal of Systems and Software)
  • Online articles, Technical Blogs and publications
  • White papers
  • Conference Papers