Infrastructure as code. What!!! ? Why ???

I logged into my facebook account today and see a different look and feel. Honestly I was quite happy the way it was earlier , I hope facebook roles back. But as a Software Developer myself what amazes me is the ease with which facebook is able to roll such updates regularly and takes several decision based on sentimental analyses of how the new features are perceived.

I thought of digging in more and understand how do they do this.?

Just imagine a seasoned operations engineer who does regular tasks of provisioning and managing the plethora of environments.The tasks could be know all the admin consoles . The engineer now exactly when the next application release is due and also know when to expect the next update to the OS. The engineer is the master of his domain. Is that good enough in today's environment. With systems becoming virtualized and as developers have started practising Continuous Integration (CI), things have started to change. The number of environment and their instances you have to deal with has gone up by several orders of magnitudes. Developers now don’t release updates and new versions every few months; they are pumping out CI builds daily. In fact, multiple builds a day. All of them need to be tested and validated. That requires new environment instances to be spun up, fast. These builds also often come with configuration changes. Logging into consoles to make each one of these changes individually is no longer a viable option. Furthermore, the need for speed is critical.

So then how to deal with this situation ?

By modelling IT infrastructure and application delivery as code. When soft wares work reliably on code why not deployment and delivery.A code can Can Accelerate Time to Market, Code Can Encourage Innovation since the time being consumed in repetitive tasks can be taken care by the code.Code Can Scale.Code is Consistent.

Code provides a way to describe and automate infrastructure and processes. Infrastructure becomes testable, versioned and repeatable. It becomes part of Agile process.

By automating your application deployment and delivery vehicle, it becomes easy  to quickly roll out changes ..

FaceBook is great example of successfully implementing infrastructure as code .

Coming posts we will try to do this .

What is a mobile app?

I got a query recently, “can you can implement devops for mobile apps?” . Which made me question, what is so special about mobile apps. Why do we have to think of devops for mobile aaps . So I thought of first try and find an answer to What is an mobile app?

What is a ‘Mobile ’ app after all?

“A mobile application is a software application designed to run on smartphones, tablet computers and other mobile devices. “

So then what are mobile devices.?

I thought of finding the definition for the same at Wikipedia.

“ A mobile device (also known as a handheld computer or simply handheld) is a small, handheld computing device, typically having a display screen with touch input and/or a miniature keyboard and weighing less than 2 pounds (0.91 kg).”

Really..? Well that's not what I thought it to be , even though the definitions can be treated as a subset of what I had in my mind.

I would further qualify that in today’s world one would limit the definition of mobile devices to ‘smart’ devices.Those with active, interactive software. It’s not just iOS vs. Android vs. Blackberry.And this is just the beginning. Televisions are now smart, though not untethered yet – they need to be connected to a cable or satellite network via a cable.All cars, trucks and two-wheelers have software embedded in their engines and electrical systems, not just the entertainment, navigation and comfort control systems. They can now tell you when the tires need more air, when the air filter needs to be changes, when you are drifting out of your lane and even parallel park themselves.

I thought of asking my teenage niece as to what is a mobile app. I got an answer ..one that is available at app store. You can download on you mobile.You can install easily. You can play games with. You don't need to be techy to use it. You keep getting updates regularly of the new improvements and more importantly everything is very simple with mobile apps. Really ? Yes that's it. Mobile apps have caught the imagination of everyone. What ever myths we had for desktop applications are no more there for mobile apps.

Mobile Apps are not Web Apps

So, are mobile apps just like web apps? No, they should be just given the same priority and attention as web apps, but they have special needs. Other than all the challenges related to supporting multiple devices with multiple OS versions and form factors, mobile apps are different from web apps in many ways. Focussing on differences related to deployment:

Mobile Apps need to go thru an App Store. This is an asynchronous step that takes a finite amount of time. Web Apps can be updates as needed or are at least within control of the enterprise.

Updating Mobile Apps is a ‘pull’. You cannot force a user to update their App when you want them to. So, unless you disable the ability for your backend to connect to older versions of the App, users can keep using them, even though updates are available.

No roll-back. Unlike web applications, mobile apps cannot be rolled back. You have to release a new version and ask users to upgrade to it.

So Considerations for writing a mobile application can be.

Understand the Potential of Mobile

Target Your Audience and Their Needs

Settle on an Objective

Measure Success

Test Regularly

Develop in Phases

Be Ready to Roll Out

So Now I ask my self a question . Do we need DevOps for mobile applications ? And the answer is most definitely YES!!.

In My next post I ll try to find answers for What does DevOps means for mobile Apps.

IBM's Approach & realization of devOps.

The IBM solution for DevOps helps an organization collaborate across a broad group of stakeholders that includes not only development, but also line of business, clients, and operations teams

The value of DevOps can be illustrated as an innovation and delivery lifecycle, with a continuous feedback loop to learn and respond to customer needs.

The DevOps solution: What is needed?

Use a common set of practices based on lean thinking to maximize value through collaborative development and continuous testing (enabling continuous innovation), and eliminate any activity that does not directly benefit the customer.

Automate manual and overhead activities (enabling continu-ous delivery) such as change propagation and orchestration, traceability, measurement, progress reporting, etc.

Create a closed loop feedback mechanism (enabling continu-ous learning) in a customer facing environment

Use meaningful measurement and monitoring of progress (enabling continuous optimization) for improved visibility across the organization, including the software value delivery supply chain.

The following figure showcases the DevopOps capabilities.

The IBM solution to enable DevOps.

IBM provides an open, standards-based DevOps platform that supports a continuous innovation, feedback and improvement lifecycle, enabling a business to plan, track, manage, and auto-mate all aspects of continuously delivering business ideas. At the same time, the business is able to manage both existing and new workloads in enterprise-class systems and open the door to innovation with cloud and mobile solutions. This capability includes an iterative set of quality checks and verification phases that each product or piece of application code must pass before release to customers. The IBM solution provides a continuous feedback loop for all aspects of the delivery process (e.g., customer experience and sentiments, quality metrics, service level agreements, and environment data) and enables continu-ous testing of ideas and capabilities with end users in a customer facing environment.

IBM’s DevOps solution consists of the open standards based platform, DevOps Foundation services, with end to end DevOps lifecycle capabilities.

DevOps: Delivery Model.

The ideas and principles guiding the DevOps concept are indeed noble. Bridging the gap between the development and operations arms of an organization is of immense benefit. It has been credited for the creation of dynamic, fortified, and functional systems, characterized by adaptability second to none, with a clearly stated agenda: the improvement of service delivery. Emphasizing collaboration and cooperation between the two often opposing groups is guaranteed to bolster quality of products, as each will be a result of an intricate blend of ingenious ideas. A marriage of operational and developmental concepts will, in many ways, ease the development of systems, leading to plausible SDLCs and the most effective of ALM policies.

Lets have a look at the continuous delivery work flow

A developer working on a Agile team. in a large project, having multiple teams developing different components of the software application you are building. Developer does his work, based on the user stories they and the team are working on. At the end of the day, He do a ‘private build’ of work to verify it builds and ‘deliver’ it to a team build server. Other team members also deliver their work. He ‘integrate’ work in the common build area and do an ‘Integration Build’.

Once the application is built, at the end of every Continuous Integration build, deliver it to the next stages in the application delivery lifecycle. Deliver it to the QA team for testing and then to the operations team (the Ops in DevOps) for delivery to the production system.

To test out that the builds coming out are ‘production-ready’ they should be delivered to a staging or test area which is production like..

Continuous Delivery doesn’t mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time.

When continuously delivering software, one is not only validating the functionality and performance of the software being delivered and the environments it is being delivered to, but also the process of deploying the software itself. Deployment of the software is not as simple as copying some binaries over FTP. It involves file transfers, to multiple locations on potentially a complex set of nodes, but also involves configuration changes – to OS, databases and middleware. It also involves an orchestration of steps. One cannot simply do deployment steps in a mechanical linear manner. Middleware processes may need to be restarted after configuration changes. Services may need to be stopped before file transfers and then restarted, all in a coordinated orchestrated manner. Hence, continuous delivery allows for these processes to be tested and refined to ensure that when it comes to the final deployment to production, it is not the first time the team is executing the process(es). They are tested and proven to work.

In the flowchart above the Automation Agent for the delivery process takes care of deploying the resources to similar environments once the necessary artifacts are provisioned.

Coming next is to learn about DevOps Capabilities and IBM's tool chain to realizes devOps.

DevOps Principles cont.... CTCM

Continuing to where we left in the last post are next two principles of DevOps.Continuous Testing /Continuous Monitoring which are facilitated by continuous integration .

Continuous Testing

Continuous Integration and Delivery are both (almost) meaningless without Continuous Test. Not having motoring and hence, not knowing how the application is performing in production makes the whole process of DevOps moot. What good is having an streamlined Continuous Delivery process is the only way you find out about your applications’ functionality or performance being below par is via a ticket opened by a disgruntled user?

Continuous testing reduces the cost of testing while helping development teams balance quality and speed. It eliminates testing bottlenecks through virtualized dependent services, and it simplifies the creation of virtualized test environments that can be easily deployed, shared, and updated as systems change. These capabilities reduce the cost of provisioning and maintaining test environments, and they shorten test cycle times by allowing integration testing earlier in life cycle.

Continuous Monitoring

In Production, the Ops team manages and ensures that the application is performing as desired and the environment is stable via Continuous Monitoring. While the Ops teams have their own tools to monitor their environments and systems, DevOps principles suggest that they also monitor the applications. They need to ensure that the applications are performing at optimal levels – down to levels lower than system monitoring tools would allow. This requires that Ops teams use tools that can monitor application performance and issues. It may also require that they work with Dev to build self-monitoring or analytics gathering capabilities right into the applications being built. This would allow for true end-to-end monitoring – continuously.

Putting The Four Continuous principles of devops

• Continuous Integration
• Continuous Delivery
• Continuous Testing
• Continuous Monitoring