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

Mobile dashboards and efficiency

For years businesses have worked with and focused on desktop dashboards but given the increased mobility and rise in the use of tablets versus PCs in recent years the mobile dashboard has come into the spotlight. While this is but of course a natural progression, the part where things get sticky is how mobile dashboards are created.

Dashboards imported over from the PC version

This is the cheapest way to create a mobile dashboard. Here the dashboard is literally imported over from the computer version as a picture or opens up in a web browser. The user has to scroll on the device to be able to view the entire dashboard!

This is also the worst way of creating a mobile dashboard if the goal is an efficient dashboard.

Squeezing a dashboard meant for a computer screen in to a phone or tablet screen results in what one can only call abstract art.

Dashboards in pieces or Dashboardlets

A dashboardlet can best be described as an independent screen created for a mobile device which when combined with others like it forms a full screen dashboard for a computer.

While this method is better than the previous one it still does not create what one can call a complete dashboard experience on either device. The reason being that while it is created for a mobile device it still has constraints due to the fact that it needs to be fitted on to a computer.

A mobile native Dashboard

The rarest of all three and by far the most efficient is the mobile native dashboard. This dashboard is designed to the specifications of a given mobile device – tablet or phone.

It is completely separate from a computer or web dashboard even if it utilizes the same data sources.

The real estate on a dashboard is considered rather precious but that of a mobile dashboard is even more so. By choosing dashboards especially created for such a space, organizations can maximize the ROI on a mobile dashboard.

In this age of instant gratification not only does a mobile native dashboard make navigating a dashboard on such a device intuitive for a user but, as the Captain Dash team has observed, makes it as quick and as fun as any other mobile app.

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

Love that KPI, but let it go!

There is a saying that if you love something let it go, if it comes back it was meant to be. Sometimes companies tend to latch on to their KPIs for too long. The question is how long is too long? There are three ways to figure out if it is time to let go of a KPI:

The KPI has achieved a target and is stagnant

KPIs are meant for measuring very specific metrics and should have specific goals that define the purpose of the KPI. The basic idea behind this is to put into place improvement measures that help the team to achieve those goals. But, the fact is that not everything can be improved upon forever.

For some KPIs when they reach their goals the organization needs to take a step back and ask whether they are a priority anymore or not. If these KPIs have a lower priority since they have achieved their goals as opposed to KPIs that are still in progress then it is time to let those KPIs go.

It is better to pour resources into things that actually need to be improved instead of trying to improve something that has already reached the desired level of improvement.

Change of strategy

As a company grows and changes there are bound to be changes in the strategy and future goals. If the organization has a set of strong, well performing KPIs then their KPIs will be well aligned with their goals and strategies. As changes come about some of these KPIs will no longer be in alignment with the new strategies.

If a KPI no longer aligns with the goals of an organization or a team then it needs to be let go to make space for one that does.

Usefulness

Choosing KPIs is a science but also an art. There are times when a chosen KPI does not measure up to the expectations a team may have had. In the case where a KPI is found to not serve its purpose or found to affect other areas negatively it needs to be let go.

Letting go of KPIs does not mean to just discard them. It means that they do not have a place on your dashboard for the moment.

When letting go of a KPI the best practice is to archive the KPI so that it can be retrieved as and when needed.

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

KPIs – R is for relevant

It is commonplace for an organization to use the S.M.A.R.T. rule for their KPIs. This rule, in short, states that KPIs should be S.M.A.R.T. – Simple, Measurable, Attainable, Relevant and Time bound. While this framework definitely provides a good foundation it is rather easy to end up with KPIs that do not achieve the desired results. The reason often is the misinterpretation of the ‘R’. Most people make the R about the enterprise, i.e., KPIs should be relevant to company goals.

What about the individual who has to work with these KPIs? Simply put it is not possible for the KPIs to be adopted across the company if they are not relevant to the individual worker.

At Captain Dash when we counsel our clients on KPIs we focus on aligning individuals to the KPIs by keeping the following factors in mind:

Target Audience

The first thing is to understand who has direct impact on the KPIs of the company. How can a KPI be made relevant when the person who directly affects it remains unidentified?

People Study

The next step is to understand the environment in which the target audience functions. What are the factors that have an effect on their ability to deliver, what motivates them, what are the constraints they function under, what are their personal goals for their work, how do these goals align with the intended KPIs?

Gap Analysis

The last part about goal alignments is extremely important. A misalignment between personal goals and company goals can have a negative effect on KPI selection. Once the goals of all the stakeholders have been identified a gap analysis needs to be performed. This gap analysis serves as a blue print when choosing KPIs that are beneficial to both the stakeholders and the organization.

Control

The last step to selecting relevant KPIs is to make sure that they are actually actionable. KPIs that individuals have no control over serve to do nothing more than add frustration and a feeling of failure, neither of which is good for an organization in the long run. Moreover it is impossible to motivate people with something they have no control over.

Once KPIs have been shortlisted keeping individuals in mind all that needs to be done is discuss these KPIs with the respective people under whose domain they fall and help them align their teams to these KPIs.

So, while there is no ‘R’ in KPIs remember that there are no KPIs without relevancy.

Written By: Meghna Verma

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

Sexy Data = Smart Data + Beautiful Data

At Captain Dash we believe that data is sexy. Data is smart enough to tell a story and beautiful enough to delight your senses. Or at least it can be all those things. Smart Data

The world is already overwhelmed with data and the number of devices producing data outnumbers humans. This number is all set to explode by 2020.

What this means is that data is not going away and it IS the future.

As data has increased everyone has jumped on to the bandwagon of creating metrics. Everyone wants to know every possible thing that data can tell him or her.

As a generation we have become pros at adding performance metrics to as many things as possible – our health, our businesses, dating sites, even our social interactions!

But these metrics are just numbers again without the right context and the right vision. This is where story telling comes in. All the data that you or your business generate can tell a fascinating story when the right KPIs are applied to this data along with supporting facts, understandable charts and finally correlation.

Beautiful Data

Humans are visual beings. Not only do we judge people and things based on how they look but we digest information in matters of seconds when represented visually as opposed to the minutes or hours it would take to read it or listen to it. On top of that it is easier for us to retain a picture over a book.

So, of course visualizing data is key. But visualizations needn’t be boring pie charts. Visualizations should be harmonious, sleek and impactful!

They should make the viewer stop and spend time on them.

Sexy data

When you combine these two elements, the correct data with beautiful visual representations of it’s story, you have on your hands what we call sexy data.

This is the kind of data that is intuitive, hits the mark and is appealing to look at.

Going forward, the success of data depends entirely on turning the vastness and complexity of data into something simple and intuitive enough to attract its viewers.

Hence, how sexy your data is depends on how smart and beautiful you make it!

Written By: Meghna Verma

Consumers Are Players In The Game Of Marketing

The market is a multi player playing field. And the consumers are players too! Now, consumers can either play with brands or against them. Let me explain.

The fact that marketing and branding have been a focus for protests is nothing new. It is simply proof that advertising and marketing have become powerful. The new thing is that the opposition to brand names is no longer limited to ideological groups like Greenpeace or leftists.

With the development of digital networks and a new post-industrial consumer culture, it is ordinary consumers who wake up one morning and decide to play not with brands, but against them.

These are protesters who forsake official demonstrations for ‘flash mobs’ and press announcements for ‘posts’. Their weapons are blogs and social networks. They work in their pajamas, safe and warm at home, drinking soda to stay up all night online.

Their power is absolute. It is measured by their Google PageRank and the number of hits they receive.

Fighting a brand becomes a game. Points are tallied. Just as in a game, the raison d‘être is to free yourself from the rules, to master and transform them.

“Such and such a brand wants to impose this product or rule of consumption on me. Well, I have the power to challenge it.”

“This brand is dishonest; this product is of poor quality. Well, I have the power to advertise the fact.”

Consumers are therefore far more dangerous for brands than politically active groups, because their discourse is not ideological, but real consumer speak, which is far more likely to convince the vast majority.

This alone is a profound change in the relationship between brands and consumers. We no longer have complete power over the consumer. We are now in an equal marketing relationship.

Not only do consumers decode marketing strategies but, better still, they are capable of producing new ones or subverting them for the purposes of social or political mobilization.

With new media it often means that certain particularly skilful consumers have a greater capacity to distribute information on a large scale via the Internet than groups with a wealth of financial power at their disposal. The development of image alteration tools coupled with the viral effect means that anyone can become a marketing agent.

It also means that instead of playing against you they can play for you. They can be your voice, your brand ambassadors, your community leaders and your heroes.

These new consumers, symbolized by bloggers, instagrammers and social media savants are constantly on the move and it is up to the brands to internalize the idea that consumers have the power. The brands that understand this have a significantly better chance of coming out victorious in this game than those who do not.

Written By: Bruno Walther

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

 

Micro Services - Code Small Enough To Remove

As a general rule the delivery rate of all commissioned software is pretty low when we take into account the total amount that are commissioned versus the amount that are actually accepted and used by a somebody. Over that when it comes to business software in particular the average life is about 5 years before it becomes obsolete – dead! When software is created one usually ends up with big hulking monoliths that have very tightly coupled components, thus, making them difficult to deploy. To ease that developers add layer after layer of complexity until we are left with a system that is too big and too complicated to actually function.

One can say that most of the work created a software engineer’s lifetime is sooner or later non-existent. The reason behind this is that historically most software has been so difficult to change that it is easier to kill it and start anew.

This killing of software systems is a strange thing considering that the world we live in is made up of extremely complex systems that thrive and function for years. The biggest example of that is the human body.

With everything one puts the human body through it should not survive for years at end and yet it does. Why is that? The answer is that it is self-regulating. The human body constantly discards cells that are irrelevant, old or have lived out their lifetime and replaces them with newer cells.

If we want software that lasts for our entire life times then it needs to be easy to change and should weather the changing technological environment. For this we need our software to mimic the human body!

In order to do so we would have to discard parts that are becoming obsolete and replace them with newer and better parts. For us to be able to do this with a systems architecture we would need Micro Services.

Why?

Because these parts would have to be small, very loosely couples components that can easy to discard because they aren’t coupled and replace because they are not long and complicated.

For these parts to be high performing the best route to go would be for them to be written in the language that works best for each individual part. Additionally it is difficult to tightly couple components that are written in different languages.

This decoupling of components leads to failure. The good thing about knowing that you have increased chances of failing is that you are prepared to fail, thus making it easier to recover and create better codes.

These are all factors that Micro Services make possible. Micro services make it possible for us to create code small enough that we can remove it without fear and systems that can live forever.

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

Written By: Meghna Verma

Swarm Intelligence and Organizational Structure

Ants or bees are not exactly the most intelligent creatures in the world, individually speaking. Yet, get a million of them together and they manage to migrate, build gravity defying architectures and create very complex social systems. How do they do it? They combine their intelligences to form one big collective intelligence. Scientists call this collective intelligence Swarm Intelligence.

Swarm intelligence can achieve feats far beyond the capability of an individual. Most of the animal kingdom is ruled by this intelligence, in small or big groups. How swarm intelligence works for so many varied species is that it is based on the following 3 principles:

Flexibility – The ability of the group to change course or get creative when faced with an obstacle.

Robustness – Even if one individual cannot perform, the group can.

Self-Organization – No clear hierarchical leadership resulting in central control or supervision.

In fact, it is very rare to find a natural top down structure in nature where there is central control. For example, if the human body were organized according to a top-down structure, all the cells in the body would need to consult with the brain before acting. We would be literally incapable of moving and thinking at the same time.

Now, this holds true for companies that need to manage flows of information and be creative and innovative as well. Yet, humans love top down rigid structures, especially in business organizations.

Traditionally hierarchical organizations are structurally incapable of adapting to change and are incapable of taking new information onboard. Information has to reach the top of the pyramid before coming back down. It is a waste of time and a loss of efficiency that affects the company's creative potential and profits.

Successful companies have understood this. Highly innovative companies such as Google, Microsoft and Dreamworks have a dynamic, shifting network organizational structure. Teams are constantly forming and dissolving.

This kind of a structure is not flat. It is ever changing. It is cross-functional. This kind of structure, as we have discovered at Captain Dash, works very well when you are working with Micro Services. Instead of teams we have hubs. These hubs grow and move to make space for talent. New hubs can be created without damaging existing hubs.

The most successful managers will enlarge their hubs. Individuals know that such a system enables them to flourish. Their career will be determined by their talent, not their political ability to climb a pyramid-shaped structure.

This system is effective because it is natural.

There is no obstruction to the flow of information and chains of command are short.

Managers behave more like entrepreneurs than soldiers.

The key to success is the flexibility of decentralized networks.

Written By: Bruno Walther

 

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

The KPI Curse

KPIs have a way of turning many organizations on their heads. Sometimes this happens because there are too many KPIs and too much data being gathered but often times it is because KPIs are misunderstood.

KPI stands for Key Performance Indicator with the emphasis being on indicator though people often tend to put the emphasis on performance. Due to this, KPIs more often than not become very closely entangled with targets.

At Captain Dash when we consult with our clients over KPIs we advice them to narrow their KPIs down to metrics that are closely related to the global goals of the organization.

By this we mean that KPIs are not the goals themselves; instead they are indicators of said goals. For us, KPIs help us to measure certain data points that help us to determine the progress made towards achieving our goals and delivering on our key priorities. This thus implies that KPIs indicate whether we are on track or not. They exist to provide objective information, which helps us to strategize better.

If on the other hand when one uses KPIs as targets they end up as short-term numbers to be achieved by departments and just serve as a scorecard more than anything else.

There is of course a reason why KPIs and targets get mixed up together. Other than the fact that they are both metrics there is the fact that for KPIs to work they need targets or benchmarks. It is very easy to see these targets as the targets that the organization or departments need to achieve.

Do not let them confuse you, these benchmarks serve as a reference point to see if we are on track and how much adjustment is needed, if any, in our strategy.

If you use KPIs are the indicators they are meant to be and let them guide your strategy they end up as very powerful tools to guide improvements across the organization.

On the other hand, an indicator that you could implement to measure progress could be the Key Transformation Indicator or KTIs.

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

How to Read a Sankey Visualization

n dimensions + 1 metric

Shows the distribution of a metric on several dimensions, with the value of each dimension’s distribution shown on the next dimension.

Example : It’s possible to distribute the “visits” metric on a “types of visitors” dimension where the values could be “new” and “known”, then distribute the “new” and “known” on a dimension “sex” between male and female.

For Example: Let's say you want to track the entire journey of your visitors. Which channels do they come from? Which pages do they land and leave on?

You can clearly see that the majority of your visitors are new.

Sankey New visitors

Most of your new visitors come directly to your website via url, but a significant portion also come from referrals.

sankey referral

Your known visitors mostly come from organic search.

Sankey organic search

All of your organic search visitors accessed your website from google.com, and most of your referred viewers come from designmodo.com, designfestival.com or forum.vietdesigner.net.

sankey google

sankey designmodo

What about landing pages?

Direct and organic search visitors land on /the-company, /the-product or /home pages.

sankey companyUh oh...your referrals are landing on your /404 page.

sankey 404 You must have removed a page from your website which was referred to by an external link. Something must be done about your 404 page and your /511 page because people land on it and leave without ever finding your home page.

Is this the journey you had in mind for your visitors?

In order to play around some more with Sankey Visualizations you can head over to the visualization lair at Captaindash.com.

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 .

 

How to Read a Treemap Visualization

1 dimension (hierarchical or not) + 1 metric

A Treemap visualization represents a hierarchical dimension by encoding a metric on each node of the hierarchy.

Example : The hierarchical dimension of geography. On the first level, we can see the distribution of the metric between continents. We can then explore a continent to see the distribution between countries, etc.

Let’s say you want to check out where your visitors are located.

 

 

Treemap Captain Dash 1

Let's Analyze A Bit

At a mere glance, we can see that nearly have of your visitors are in Europe, a quarter in the Americas, the remainder in Asia, and but a few in Oceania and Africa. The “Explore” button gives us a closer look at Europe, revealing that half of those visitors are in the West and the rest are split evenly between North, East, and South.

Treemap Captain Dash 2

Another “Explore” click and we see that more than half of your Western Europe visitors are in France.

Treemap Captain Dash 3

A look at the Americas reveals that the United States accounts for 86% of viewers on the continent.

Treemap Captain Dash 4

Is that where you should open your new office?

In order to play around some more with Treemap visualizations you can head over to the visualization lair at Captaindash.com.

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