Fundamental traits of Micro Services

Micro Services work best when deployed in groups. Their numbers make them a complete system and today we will touch upon the underlying fundamental traits that make it possible for them to work the way they do. Single Purpose

A Micro Service should have only one single purpose. This means that it should not only do one single job but that it should have just that one single reason to be changed, stopped or paused as well.

This can sometimes become complicated for enterprises to follow since a single purpose can perhaps have sub-parts to it. In such a case do you create many micro services to handle each sub part or does one service handle the whole set?

To figure this out the other traits of Micro Services should also be looked into.

Non-Sharing

Micro Services do not share anything with any other services. The function and data of each one is its own. If one service needs something from another one it has to go through established communication protocols so as to not disturb the microcosm of the other.

Private Data

Each Micro Service manages its own data center and storage format. The reason for this is so that the data is not changed in any form due to being used by another service.

A Micro Service has established APIs and communication protocols for other services to ask for access to its data.

Private Deployment

Every Micro Service has its own deployment process, which means that there is no deployment library from which various micro services are deployed.

The reason behind this is that if there is a library or services then for each time an application runs a process a whole set of services will need to be deployed instead of just one service. This increases run time and reduces decoupling.

Just like with the data, if an application wants to deploy a Micro Service it needs to do so by using established APIs and communication protocols.

Since Micro Services tend to work in groups more often than not it is best practice to establish a system where each one gives regular status updates since keeping track of an entire architecture of Micro Services would become increasingly tough if they didn’t.

To stay updated with our series on Micro Services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma

What comes first? Micro Services or Micro Segmentation?

It reads like the chicken and egg story only in the case of Micro Services and Micro Segmentation it is very easy to think that they come as a package deal and thus confuse the two. Micro Services

As we have often discussed on the Captain Dash blog, Micro Services refer to a set of services or mini applications making up the application architecture of an organization.

An organization can either break apart an existing Monolithic application to create Micro Services or it can create its architecture as a combination of several Micro Services from scratch.

Micro Segmentation

Micro Segmentation on the other hand deals with breaking up of a network itself. This could be done for several reasons, foremost of which is security.

The point to note though is that when a team uses the Micro Services approach to their architecture a natural bifurcation of the network occurs thus leading to Micro Segmentation. This is also the reason why there can be confusion between the two.

Another significant use for Micro Segmentation is that aside from taking the pressure off of one large network is that it isolates disruption when services need to be changed or upgraded. In case of a single large network one change can have domino effect on the whole network.

Micro Services and Micro Segmentation

In brief these are both methods of segmenting a Monolithic architecture in different domains and turning them into smaller, more scalable and secure components.

Just because a team uses one approach it doesn’t automatically mean that the other follows. Though it is best practice to employ both for optimization.

While one cannot say which one comes first, as a general rule it has been observed that if a team uses Micro Services then Micro Segmentation is quick to follow. On the other hand the employment of Micro Segmentation does not necessarily result in the use of Micro Services by a team.

If your organization has made the switch to Micro Services or to Micro Segmentation we would love to hear which came first for you.

To stay updated with our series on Micro Services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma

Micro Services – Dealing With The Turf Wars

This past year we have witnessed how many companies have successfully integrated Micro Services into their architecture. In fact, 2015 has been touted as the year for Micro Services. It is all very fine for certain visionaries in an organization to push for Micro Services adoption from a strategic point of view but it is often found to be difficult to get people on board. Now, if it is indeed that great of an idea then why is it so difficult to convince teams to adopt them?

The answer is very simple – Turf!

Mostly the data in organizations exists in silos and is utilized as such. The problem that Micro Services present to such a way of functioning is that they represent a different way of doing things where managers often have to loosen their hold on their data. Thus, turf wars come into play.

There are some measures that can be taken to make a smooth transition in such a case:

  • Start by creating Micro Services for new application features to begin with. As development progresses work on refining and making changes where they need to be made.
  • To begin with keep the teams working on Micro Services separate from the team working on the monolithic architecture.
  • Provide the time and support to various teams to explore how Micro Services work and incorporate them into their work process.
  • As the Micro Services structure progresses encourage the teams to intermingle, have exchanges and facilitate cross training of skill sets.
  • As the skill differences become smaller and the comfort level of various teams increases start the breakdown of silos – both in terms of teams and data utilization.
  • As the Micro Services architecture expands start sliding slowly from the monolith to micro services.
  • Create standardized templates for development to make the creation of Micro Services easier.
  • As the architecture and the culture it brings get accepted across the organization start pruning the older Micro Services and replacing them with finer, more current ones.

While, it may be difficult to get everyone in an organization on board with Micro Services it is well worth a try as it can not only create better, more scalable software it can also help build better team dynamics.

To stay updated with our series on Micro Services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma

Micro Services - Preparing for the Transition

We have often talked about how working with Micro Services brings about changes at many levels in an organization. Today we will tackle the how to prepare for these changes to come and the transition can be made smoother.

The 3 main things to consider are services, dev-ops coordination and security.

Services:

Aside from changing network speed and construction, Micro Services tend to have a huge effect on the services associated with the applications. Given the loose coupling necessary to obtain a functional Micro Services architecture the dev and operations teams need to divide their network services between those directly associated with applications and those that are not.

Service discovery needs to be implemented as well. The tool used for this needs to be equally dynamic on and off cloud. The service discovery has a direct impact on your infrastructure since it affects how the services interact.

In addition to all this the rise of containerization services has led to a need for compatible management services to make the workflow smoother.

Dev-Ops coordination:

Making the transition to Micro Services is not especially easy on teams and because of this the development and operations teams need to work in synchronization to facilitate this transition.

Ideally in a Micro Services structure exclusively one team from start to finish handles each application, but often, if your team is small this does not happen. Instead the team is handling multiple applications and sometimes working with other teams. In such a scenario the operations and development schedules need to be synched to perfection to make for smooth deployment.

Security:

Security is not something one thinks of first hand when considering transitioning to Micro Services. The biggest advantage of this infrastructure is the agility it affords and every malicious attack that your security blocks, is one less stress on your application. Thus, a sound security system helps your applications to perform stress free and with the required agility.

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma

Three architectural strategies for Micro Services APIs

A good house is built on a strong foundation. The same holds true for systems architecture. How you build your Micro Services determines what they turn into.

Read more

Nous aimons l'échec

Echouer est le meilleur moyen de réussir. Notre choix d’architecture reflète cette philosophie.

Dans tout service il y a des erreurs. Qu’il soit monolithique ou construit à l'aide de micro services, il peut tomber en panne à tout moment. Le travail d'un éditeur est de détecter ces erreurs et les réparer rapidement.

La structure monolithique est complexe. Elle est par essence difficile à tester, déployer et maintenir.

Les micro services sont eux construits pour supporter ce type d’échecs. La pluralité des services minimise leur interdépendance. La panne de l’un ne fait pas tomber l'ensemble du système.

Une architecture de micro service est structurellement sous surveillance. On peut ainsi, comme le fait le programme Simian Army de Netflix, tester ses limites et l’améliorer infiniment.

L'écriture minimaliste du code, la vitesse de déploiement, la capacité à réparer et modifier chaque application individuellement nous donne la flexibilité nécessaire pour innover et tester aussi souvent que nous le voulons.

Cette flexibilité nous permet d'assumer l'échec. Et l'échec est la source vive de l'innovation. Nous pouvons innover, tester, nous tromper sans perturber l’ordre des choses.

Ne pas avoir peur de l’échec permet aux équipes de repousser les limites et les normes et de réaliser l’impossible.

C’est cette capacité à accepter l'échec qui nous fait aimer les micro services.

Note : Captain Dash commence une nouvelle série d’articles sur les Microservices. Certains sont techniques, d’autres moins. Notre objectif est de considérer cette forme d’architecture que nous utilisons et de la rendre compréhensible pour le commun des mortels. Ces articles seront publiés tous les dimanches. Donc suivez-les sur Twitter ou abonnez-vous à notre blog et recevez votre mise à jour hebdomadaire sur cette fabuleuse architecture qui est en train de changer la façon de faire des affaires !

 

Micro Services - A Case for the Sidecar

One of the most fascinating traits of Micro Services is that they are polyglot or as we like to say here at Captain Dash – they are a Google translate that works.

There are obvious advantages of such an architecture, the biggest being that we can use the best tool for getting a job done.

On the other hand it has its fair share of challenges, the most prominent one being that separate libraries need to be maintained for each language used. While such an overhead seems acceptable for 2-3 languages, what happens when we are dealing with 6-8 of them?

Organizations traditionally used virtualization to tackle this issue but with the arrival of Docker on the scene most have moved to containers because of lower overheads. But, containers in Micro Services do exactly what they do in a home – they hide the mess not get rid of it! In this case the libraries still need to be built to facilitate communication except they are containerized.

Here is where sidecars come in. Named after the sidecars on a motorcycle a sidecar is a second application that runs alongside the Micro Service it is attached to and provides a language neutral interface for the micro service to communicate with. It can be said that a sidecar is a glue code that allows for the assembly of various Micro Services components.

Many teams are currently employing sidecars successfully for example Netflix and AirBnB.

They do, of course, come with certain disadvantages. The most obvious being that in process communication is smoother and less prone to bugging. Another issue being that sidecars cannot effectively access all the information inside the parent application.

There is also the point to consider that eventually sidecars will become obsolete because the Micro Services systems are evolving even as speak. Until that happens though the sidecar pattern is a great tool to add to your Micro Services set to facilitate communication and language neutrality.

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma Meghna Verma is the CMO at Captain Dash.  You can reach her on Twitter @M3GV3RMa .

 

Micro Services are not a Silver Bullet

if you can’t build a well-structured Monolith, what makes you think you can build a well-structured Micro Services system?

Read more

Micro Services - Reasons For Partitioning?

A few posts back we spoke about how Microservices affect organizational structure and how the structure of an organization mirrors the structure of its architecture. By structure of an architecture we basically mean partitioning of that architecture and hence the organization.

So, now we are faced with the question of why should one partition the system? The simple answer, of course, is agility. The biggest reason for any organization to switch to Micro services is to be agile.

And agile is all about individuals; how they decide to work together and build software that are aligned with their business goals.

There are a few broad reasons why businesses partition either their organizational or their software structure:

Comparative Rates of Change

Different parts of a system often have different rates of change relative to each other. Some portions might need to be changed on a weekly basis while others annually. In a case such as this a partitioning is usually required so as to make the more frequently changed parts to be more independent.

Autonomy of Teams

Sometimes it is easier to split up teams and systems so that different teams can work independently on different parts of the system without being affected by each other’s work and speed. Here the teams are usually created so as to mimic the independently partitioned system parts.

Domain Boundaries

A complicated system often calls for extremely strict and independent boundaries of its business domains. This is to make it possible for each business unit to be completely self-sufficient and thus be independent of the functioning of any other unit. This is usually what we called decoupled business units. Having separate teams and modules taking care of these domains is usually a good idea.

Non-Functional Facets

Usually different parts of a system will have differing non-functional facets, which put them at odds where, needs and resources are concerned. This is the reason that Monoliths are difficult to scale since the entire system needs to be scaled even if only one single component needs it. This is another reason businesses consider partitioning their systems since doing so helps them to better assign their resources and invest their energies.

The bottom line? No matter what the reason for the partitioning maybe the goal is agility!

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

 

Written By: Meghna Verma Meghna Verma is the CMO at Captain Dash.  You can reach her on Twitter @M3GV3RMa .

4 great videos to watch on Micro Services

1. Practice Considerations for Micro Services Architecture By Sam Newman, tech consultant @ ThoughtWorks

Screen Shot 2015-07-07 at 15.59.38

 

A great talk on the practical aspects of the Micro Services architecture. Sam Newton talks about things you need to learn along with the challenges you can face and how to go about navigating your team through the implementation of such architecture. He talks about his own experiences and what he learnt from his own failures.

2. Services and Rails: The Shit They Don’t Tell You

By Brian Morton , software engineer @ Yammer

Screen Shot 2015-07-07 at 16.08.49

Brian Morton from Yammer talks about how to build services and integrate them into rails. This talk looks into mistakes made, solutions that worked for Yammer, monitoring cost versus viability, teams and how Yammer has ben able to move quickly. Overall a comprehensive talk that is easy to follow even for non-engineers.

3. Microservices

By Martin Fowler, programmer @ ThoughtWorks

Screen Shot 2015-07-07 at 16.01.44

A video by Martin Fowler has to be included in this list. This video discusses what are Micro Services, what they do, how they differ from monoliths and whether they are such a new concept after all or not. This is a basic, introductory talk on the subject by one of the people who has explored it in great depth. His blog is a great read too for someone interested in further information.

4. The Business Benefits of Micro Services

By Russ Miles, chief scientist @ Simplicity Itself

Screen Shot 2015-07-07 at 16.02.24

A short, to the point video on how Micro Services can benefit a business beyond the dev team. This talk is for everyone whose company has invested in or is thinking of investing in a Micro Services architecture. It helps people who are the most removed from technology in an organization understand exactly how Micro Services can help a business compete and stay alive.

To stay updated with our series on Micro services architecture follow us on twitter or subscribe to our blog.

 

Written By: Meghna Verma Meghna Verma is the CMO at Captain Dash.  You can reach her on Twitter @M3GV3RMa .

Micro Services - Communication Between Services

Applications change with time and need but the business capabilities stay the same. Aligning our services and thus, the teams around our capabilities help us ensure that communication is not a hindrance.

Read more

Monolith to Micro Services - Refactoring a Monolith

So how does one refactor a Monolith? It is not often that we are awarded the opportunity to start with a blank page where service architecture is concerned. In fact some of the most successful Micro Service based architectures that we see today started out as Monoliths!

Read more

Micro Services - Google Translate That Works!

To put a layman’s twist into this let’s say that micro services are a Google translate that actually works!

Read more

Micro Services - Built For Failure

At Captain Dash we love to fail!

Why, you ask? Because, failure, is the best way to succeed. And our choice of architecture reflects that.

Failure

In any service there are bound to be glitches and a service can fail at any given time, be it Monolithic or Micro Services based. As the service provider it is our job to detect those failures quickly and to repair them.

In a typical Monolithic structure, due to the complex layers, it is often difficult to detect the source of failure easily and then to keep in mind all the internal dependencies to make sure that something else is not affected in the repair process. Finally the actual testing and deployment takes a long time.

Micro Services on the other hand are built for this kind of failure. The idea behind the multiple decoupled services is that when one goes down the others are not affected. Further, given the emphasis on coordination and event collaboration there is a tendency to monitor the structure constantly. This results in purposefully crashing the applications just to see what they can withstand and how they can be bettered. An example of this is the Netflix’s Simian Army that we talked about in our post about anti-fragility.

Given the size of the code involved along with the speed of deployment the ability to fix and change each application individually provides us the flexibility to innovate regularly and test as often as we please. This flexibility to innovate is what gives us the confidence to fail and thus create at a rate fast enough to be agile and cause disruption.

Ultimately it is the confidence to fail that gives a team the confidence to push the limits of the accepted industry norms, to seek out what is deemed impossible. This freedom to create that Micro Services allow us is what makes us love failure.

To stay updated with our series on Micro Services architecture follow us on twitter or subscribe to our blog.

 

Written By: Meghna Verma Meghna Verma is the Content Manager at Captain Dash.  You can reach her on Twitter @M3GV3RMa .

 

 

 

 

 

 

 

 

Micro Services – The Dark side

the-dark-side1

We Never Promised You A Rose Garden

Micro Services work well because they reduce friction; they allow for flexibility and innovation.

They also increase risk!

One might argue that they are built for risk taking but that risk is worth nothing if the ROI is minuscule. The first problem is that Micro Services have a big upfront cost. Maintaining the cost of production for multiple services, testing, deploying and running them is no walk in the park.

Having a stellar team is the other caveat in order to succeed in Micro Services. All the engineers across the board need to be well versed in DevOps tools since these are very critical in the Micro Services environment. Alongside that the team needs to be comfortable with working on products versus projects. The responsibilities are multiplied.

When you break a structure into multiple little applications a lot of things become easier but the one thing that becomes complicated is the wiring and the interfaces that we need to attach to these components. If the process is not well thought out and designed backwards there can be all sorts of network latencies, lack of synchronization and contextual breakdowns.

Keeping it simple is the first rule of working with Micro Services. This form of architecture is complex enough without adding unnecessary frills to the elements. There is, with Micro Services, a danger of moving the complexity from inside the system to the outside. This is not good news since the complexity becomes harder to control and monitor.

All of these problems that Micro Services come with, though, can be mitigated with having a pragmatic approach towards a product. One can choose to start out as purely Micro Services based or to start out as a Monolith that is later refactored into Micro Services. At Captain Dash we love working with Micro Services and believe that they are the true data revolution. At the same time we make a conscious effort to never lose sight of the clients’ vision and end goal. The end goal of the client or the product is what ultimately matters.

To stay updated with our series on Micro Services architecture follow us on twitter or subscribe to our blog.

Written By: Meghna Verma Meghna Verma is the Content Manager at Captain Dash.  You can reach her on Twitter @M3GV3RMa .