If You Internet, You Micro Service!

If you are reading this post you use the Internet. You may be a developer with an interest in Micro Services or you may not be, but you use the Internet. Here is a secret I have for you, if you use the Internet then Micro Services are already a big part of your life.

The Internet as we knew it has changed significantly. You no longer have to be a developer to create a website, the maximum social interactions most people have today are via the Internet and an even more drastic change is that Apps are a bigger part of our lives than websites are.

We use Apps for everything: social websites, communication, photography, shopping, tracking our health, travelling, reading; the list is endless.

These Apps are further connected to their respective websites and backend elements to help us communicate seamlessly with our mobile devices, computers and clouds. All of this communication is very complex and as our devices and data grow the complexity increases. This is where Micro Services come in.

Micro Services and their respective APIs are what make it possible for this complexity to function in the first place. They make it possible for the developers behind them to create that seamless user experience.

But more than that what this revolution called Micro Services brings to the Internet is a break down of silos. They are not just allowing apps to communicate they are encouraging them. They make it possible for developers to connect, share and push the acceptable norms.

All the Big Data that is floating around in cyber space is of use to us only if it is connected, channelized and shared. It is of use to us because Micro Services make it useful.

We can watch a Netflix movie chosen according to our preference on our phone because these tiny services make it possible. We can shop online using an app because Micro Services make the connection.

Without Micro Services channeling the data, creating and upgrading services quickly and communicating in a dynamic manner would be a big challenge. The way we interact with our devices and with the Internet in general would not be the same.

So, if you do indeed use the Internet then you definitely use Micro Services regardless of whether you know it or not.

In fact, at Captain Dash we believe that going forward doing business without Micro Services will not just get difficult but impossible!

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

Written By: Meghna Verma

4 Slideshare Posts About Micro Services In Practice

As mentioned earlier by us, Micro Services are the real revolution in the world of data. There are many big organizations using the Micro Services architecture out there; some which have been using it for as long as 3 to 5 years. In this post we share with you 4 slideshare posts that talk about the use of Micro Services by some of the bigger players out there:

1. Scaling Gilt: from monolith ruby app to Micro Service scala service architecture

This was a talk given by Gilt Lead Software Engineer Yoni Goldberg at the NYC Tech Talks' January 14, 2014 meetup at Gilt.

2. Nike's Journey into Micro Services

This presentation will discusses the journey Nike undertook to move to a completely 100 percent cloud native architecture and the decisions behind making it happen.

3. No Free Lunch, Indeed: Three Years of Micro-services at SoundCloud

In this talk the SoundCloud team share the toolkit and strategy SoundCloud uses to keep its micro-services explosion manageable.

4. MicroServices at Netflix - challenges of scale

Sudhir Tonse and Nitesh Kant discuss the challenges faced by Netflix while using Micro services at large scale.

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

Written By: Meghna Verma

 

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 - 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 .

 

 

 

 

 

 

 

 

Anti-Fragile - Micro Services Love Stress

When it comes to architecture safety, we traditionally refer to systems as being fragile or robust. But, there is in fact a triad – Fragile, Robust and Anti-Fragile!

antifragile-microservices-and-devops-a-study-4-638Over the years, companies have invested millions in their architecture and with each passing addition these architectures grow increasingly complex till they are a mass of technological spaghetti. When faced with such architecture we are afraid to touch it with fear of completely unraveling it. This is what a fragile system looks like; a system where even the slightest change can result in a complete breakdown.

The solution routinely sold to us is to make it robust, more resilient. This solution consists of wrapping a fragile system in layer upon layer of protection – much like bubble wrapping a delicate wine glass – and these layers will need to eventually be removed to affect any changes. A robust system will at it’s best ignore changes and at it’s worst will resist change. This is dangerous in the present environment of constant change.

Micro Services offer us the third option – to build an anti-fragile system! An anti-fragile system simply put is a system that not only thrives but also benefits from stress – the stress of run time, of change, of failure. It gets better with stress and allows us to embrace change and agility.

An example is Netflix’s Simian Army. This is a tool that systematically destroys their existing system to expose weaknesses and forces the system to improve, to handle runtime conditions better and to change faster.

simian-army

Imagine a system that allows you to destroy it and comes out of that better than before! THIS is what Micro Services bring. By allowing for mistakes, stresses, and weaknesses they lead us to take leaps in innovation instead of baby steps. We can call Micro Services just another name for SOAs or call them a buzzword but what they bring to the table – anti-fragility, flourishing on change, innovation – are more than just buzzwords. They are a reality if we want to stay relevant!

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 .