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 .

Le côté obscure des Micro Services

the-dark-side1Les Micro Services fonctionnent car ils réduisent la friction; ils permettent flexibilité et innovation.

Mais ils augmentent aussi le risque !

Avec les Micro Services, les responsabilités sont multipliées.

Les équipes doivent travailler sur des produits plutôt sur sur des projets. Les ingénieurs doivent être bien renseignés en outils de DevOps.

A priori lorsqu'une structure informatique est divisée en une multitude de micro-applications les choses sont plus simples.

A première vue seulement, car connecter entre elles et produire les interfaces liant ces composants peut recréer une complexité conceptuelle et technique. Il suffit que le processus ne soit pas bien pensé et manque de réversibilité pour que surviennent des latence dans le réseau, des problèmes de synchronisation et des pannes contextuelles.

Avec les Micro Services il faut rester simples. L'informatique est par essence complexe. Il ne sert à rien d'inventer des services superflus ou de modifier des éléments qui fonctionnaient correctement.

Le vrai risque des Micro Services est d'exporter la complexité d'une informatique Monolitique en dehors du système, la rendant ainsi plus dure à contrôler et superviser.

Une approche pragmatique, orientée "produit", peut limiter les problèmes posés par les micro-services. L'enjeu est de penser "produit" et "métier" avant de penser "services" et "informatique".

Chez Captain Dash nous adorons travailler avec des micro-services et croyons qu’ils représentent la vrai révolution de la data. Mais nous ne perdons jamais de vue la vision du client et le but final car c’est ce qui est le plus important au final.

Note : Captain Dash commence une nouvelle série d’articles sur les Micro Services. 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 !

 

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

Pourquoi les Micro Services sont Votre Botox !

Certains Ayatollah des Micro Services prétendent qu'il n'existe qu'une alternative en termes de Micro Service : soit vous travaillez exclusivement avec, soit vous prenez le risque programmé de devenir très vite obsolète. Pour les tenants du full Micro Services, les choix d'architecture entre Micro Services et Monolitique sont trop radicalement opposés pour pouvoir cohabiter ensemble.

Ce n'est pas notre point de vue.

L'enjeu n'est pas de jeter à la poubelle l'ensemble de votre architecture pour la remplacer par des Micro Services. Non seulement changer d'infrastructure est une opération longue, complexe et coûteuse. Mais surtout, lorsque vous pensez Micro Services, ce n'est objectivement pas nécessairement utile.

Il est totalement possible de construire autour une architecture Monolitique un exosquelette constitué de Micro Services qui communiquent entre eux au travers d'APIs.

C'est exactement ce que nous faisons avec Captain Dash. Nos clients utilisent tous des architectures Monolitiques. Nous n'intervenons jamais sur l'architecture existante de nos clients, nous n'y apportons aucune modification. Nous nous contentons d'injecter, pour rendre le système tout entier plus agile et modulaire, des petites doses de Micro Services qui communiquent entre eux grâce à des APIs.

Botox-Injection-Picture

C'est un peu comme faire des piqures de botox juste aux endroits où les rides doivent être effacées plutôt que d'opter pour une opération de chirurgie esthétique de très grande ampleur.

Et nous pensons que c'est précisément là que se situe le caractère révolutionnaire des Micro Services. Permettre de faire cohabiter deux mondes et faire rajeunir les applications Monolititiques à moindre frais.

Les Micro Services sont aux architectures Monolitiques ce que le Botox est aux rides. Une cure de jouvence à moindre coût.

Note : Captain Dash commence une nouvelle série d’articles sur les Micro Services. 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 Allow us to Innovate!

In our two last posts on Micro Services we have discussed anti-fragility and the ability of Micro Services to survive failure.

 Related to both these qualities is innovation. Micro Services facilitate innovation at a very fast pace, thus making it possible to not only be disruptive but also remain so.

20120830_samsung_innovate

A traditional Monolithic application does not give us much opportunity for innovation. Due to the way it is built, changing things and experimenting can be risky due to the fact that the changes potentially affect every aspect. Thus, any kind of innovation is limited.

 Micro Services, on the other hand, respond very well to changes. The decoupled nature of this structure makes it possible to change each individual service in any way that works best for that particular service. The fact that this is a polyglot architecture gives the designers the freedom to work in the language that works best for a particular aspect of the system. This is not to say that the languages have to be different for it to work but just that the options are available.

Another feature that helps to keep the innovation constant and fast paced is the size itself. A small set of code is definitely easier to change and mould as need be compared to a larger set of codes. Smaller services are also easier to test and deploy thus making it possible to innovate and change faster.

The size and modularity of Micro Services ensures that even if a particular change brings down the application the entire architecture is not affected by the failure. This feature, especially, is what gives the teams the confidence to experiment and play with ideas without the fear of a complete shut down.

Anti-fragility, the ability to survive failure and finally the freedom to innovate is why we, at Captain Dash, consider Micro Services to be our secret sauce. They make it possible for our team to offer innovative, completely customised solutions for our clients – solutions that work!

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 .

Qu’est ce qu’une Application Monolithique ???

Un Monolithe est un bloc de pierre de grande dimension, constitué d'un seul élément, naturel ou taillé voire déplacé par l'Homme.

Et nous français, avons grandi avec ce symbole du monolithe ultime : le menhir d’Obelix.

Nous avons pris pour habitude de qualifier de monolithe les grosses applications, constituées d’un seul bloc, dont l’ambition est de traiter toutes les demandes que nous leur soumettons.

allocation

Ces applications sont écrites dans un langage unique. Et à chaque ajout elles deviennent de plus en plus complexes, difficiles à maintenir et déployer.

Pour faire face à cette complexité, les architectures sont souvent scindées, au plan logique et non physique, par fonction. Plus les systèmes grossissent moins ils deviennent réactifs.

Seul un Obelix, tombé dans un chaudron de potion magique à sa naissance, est capable de manipuler avec dextérité ces Menhirs de technologie.

Les Monolithes obligent les entreprises à répartir leurs ressources par projet. Ainsi on empile autant de consultants et de développeurs qu’il existe de projets. Une multitude de strates s’interposent entre le développeur et l’utilisateur final.

Le Monolithe devient une fin en soi. C’est autour de lui que s’organisent les équipes, que se concentre l’énergie.

Et c’est là que les Micro Services deviennent révolutionnaires. Ils permettent d’organiser autour des Monolithes une série de petits services autonomes, connectés entre eux par des APIs.

Grâce aux Micro Services, le monolithe qui était auparavant un Mehnir issu de l’ère Néolithique se transforme littéralement en une source de vie. Un puits inépuisable où les Micro Services pourront puiser de la data et donner vie à une multitude de nouveaux services.

Note : Captain Dash commence une nouvelle série d’articles sur les Micro Services. 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 !

Are Micro Services the Botox You Need?

So, the real question is should you be adopting a Micro Services architecture? The straight answer to that is, YES! Adopting yes. Changing your entire system from Monolithic to Micro Services, maybe not.

In the past few weeks we have propounded the various advantages Micro Services has to offer you and your business. But, let’s be real. Changing an existing architecture is not only a time consuming and logistically difficult thing to do but also immensely expensive. Much like getting an entire face job done to smooth away wrinkles.

So, what is the solution?

Recently the strongest advocates of Micro Services seem to suggest that there are only two options – either you work with them or risk becoming obsolete. Two very extreme choices of architectures, which seem to come with an ‘either-or’ label. But, there does exist a middle path that few seem to be talking about - starting with an existing monolith and adding on an exoskeleton of Micro Services APIs.

At Captain Dash, most of our clients have Monolithic Architectures while we work using Micro Services APIs. We neither touch nor change in anyway the existing architecture of our clients. Instead we work by injecting doses of Micro Services APIs as and when needed for us to make the entire system more agile and modular. I would like to say that this is like injecting small doses of Botox into you skin as and when needed to keep wrinkles at bay instead of opting for an all out plastic surgery.

Botox-Injection-Picture

We have found this method of marrying the two architectures works very well for us in terms of giving us all the advantages of Micro Services and keeping the costs and overheads to the minimal.

So, if you work with an existing Monolithic Architecture and have been spending many a sleepless moment wondering if your architecture is truly becoming obsolete and dying out, then, Micro Services could just be the Botox that your system needs!

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

Micro Services Vs Monolithic Architectures

In the last 3 weeks we have outlined in different posts the salient points of what is a Micro Services architecture and a Monolithic Architecture. This week we bring to you the main differences between the two.

[table id=1 /]

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 .

What kind of Easter Egg Hides in Your Architecture?

This long weekend as you celebrate Easter pay close attention to the eggs. Why eggs you ask? Because Easter eggs can help you determine where your business stands in terms of architecture and what are its long-term effects on your business.

chocolate-easter-egg_1427389013

Let’s start with the proverbial, large chocolate egg that one thinks of when we say Easter. This Easter egg is your standard Monolithic architecture. There is a lot of chocolate that feels good to begin with but eventually makes you sick, fat and slow. You finish it in one go or else it goes bad. A Monolithic architecture too is limited due to its huge size and all the weight it carries makes your business slow.

mini-eggs-002

Micro services architecture on the other hand, is like little mini eggs. These eggs are made of the same amount of chocolate too but are small and numerous. Thus, allowing you the flexibility of eating them as and when you need over as much time as you prefer. This means that you don’t get sick, don’t get fat and they provide just enough chocolate to give you an energy boost! Microservices with their small scalable format, too, allow you the flexibility of creating your architecture, as you want, in any language you want. Just like the mini eggs, Microservices are loosely coupled. They function as separate entities, which gives us the ability to use them in any manner we want. These lightweight codes provide the agility and scalability your business needs to stay competitive and relevant because agility will not be a competitive advantage in coming days – it will be a necessity.

At Captain Dash we have come to rely on this very flexibility of Microservices to build user centric dashboards that are quick to update, change around as required and work across all devices.

So, again, as you go about your festivities give some consideration to that egg you are about to consume!

Note: Subscribe to our blog or follow us on twitter to know read more about Micro services architecture. We put up a new post every week.

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