Wednesday, December 30, 2015

$400 million to Bankruptcy in 45 mins :(

While googling for devops case studies, i found this very interesting blog post by Doug Seven on how Knight Capital Group (an American Global Finance) failed code deployment on one of the eight production instances lead to the bankruptcy of KCG in August 2012.

At the first read I felt it may be a hypothetical case or something that is shown too aggravated. But with minimal digging I could correlate some of the facts even thought I am not totally sure about the the whole story. Anyways here the point is not about the story but about Dev & Ops nightmare.

Ignorance is not a bliss

Blog may be talking about 2012, but even today we just have a below 40% adoption of devops which seriously means lots of organization out there still doing manual heavy lifting of syncing of code between the dev/qa/prod environment. With manual intervention there is always a possibility of mistakes. If not today… tomorrow. Now the question to be asked is When or Why? Yes, with so much at stake organization cannot leave it to chance because things are fine at this point.

Human mistakes are inevitable. It may be in any form on the PDCA (Plan Do Check Act) cycle. So better to alway automate the processes which is repeatable. Definitely high risk processes like software deployments so that we have more reliability with each repetition.

Tuesday, December 29, 2015

Building MicroServices! Real Fun...

I have been coding for more than 25 years and used more than 18 different programming languages (and the framework each is good and strong at) spanning every programming style from simple scripting, procedural to objected oriented to dynamic, functional (more attractive to Software Engineering community these days). Let me confess, every time I switched to new language or style I always felt “Oh, hope I also had that”. Trust me no language is complete; no style is perfect. So only way to feast your programming appetite is try something different which gives the flexibility. I honestly think, MicroServices style of application is the one that gives the needed flexibility.

It is not said and done. We need a more pragmatic answer to the question “Why it is fun?” In my experience, the biggest challenge in designing & building software systems is that of the identification of all the bit and pieces of the jigsaw puzzle. As we know, it is never easy to identify the position of any piece when we start. We get more clarity as we start putting the bits together. But still we do the mistake of attempting to design a software system upfront in a big piece (most of the core and add additional functionality to the core which is not expandable incurring more and more technical debt). Ideally what we need is a model or mechanism through which we can identify and build smaller components and put them together with great ease. This is why we use lean agile process. But what is the use of an agile process when our engineering approach is monolithic. This is where Micro-services approach rocks.

Micro-services are small building blocks of the application which can be put together to build the complete application functionality. Keep building smaller components and weave them together. Need a new functionality? Build and deploy a new micro-service. This simple change in perception of developing application provides the flexibility of evolving the application architecture and design as we find more and more pieces of the jigsaw. This helps us in practicing the true agility in software engineering right from design and architecture, not just code development cycles.

Developing smaller blocks eases the pressure of coding and maintaining application modules. Smaller code footprints reduces dev/test/release cycles. Helps in quickly identify and fix bugs. Quickly address business process changes as we can quickly build and deploy a new service without having to fiddle with existing code.

Also, micro-services are completely independent of each of other interfacing through messages. This improves application cohesion and helps in scalability. This not only means each can have their dev and ops cycles but also they can have their own technical stack providing completely technical freedom. No challenge of deciding the completely technical stack upfront, application design dictated by technology, tech stack lock downs, challenges in getting right and enough technical resources to dev and maintain etc.,

Moreover, micro services also help in controlling the technical debt.