devopsy.kinsta.cloud

Category: Features

How to talk to your CFO about DevOps
How to talk to your CFO about DevOps

As DevOps practitioners, we understand the value of DevOps: It helps keep our infrastructures automated, allows us to push out code regularly, and reduces the frequency of breaks. But, does our CFO understand its value as well as we do? Probably not. The question is: How do you explain the benefits of DevOps to your CFO in order to justify the cost?

The quickest way to a CFO’s heart is through his wallet. So, the key here is that as DevOps practitioners we need to talk in the CFO’s language, not our own. We need to speak in dollars and cents rather than bits and bytes. This is not dissimilar to many other instances when IT departments have to work with C-level teams that are business, if not technology focused. But sometimes this is incredibly hard for IT folks to do. It’s just not how we are wired, and similarly, CFOs aren’t wired to think like IT folks. While every CFO and organization is different, there are some common things they all care about.

For example, most CFOs love to count things, especially money. Where is it going? Why? What is the benefit to the company? What’s the ROI? You know typical bean counter type of questions that make a lot of technical people squirm.

Your CFO can be one of two types and you can have a lot to do with how your CFO views DevOps. The two types of CFO are:
1. A CFO that understands the why behind DevOps and is a valuable ally to an IT organization.
2. A CFO that doesn’t understand the benefits and will stifle even the best, most productive programs.
So the question is how do you wind up with CFO number 1? Well, part of it is that you need to educate your CFO in the value of DevOps. This is exactly a situation described in “The Phoenix Project” by Gene Kim et al, but it bears repeating here. The other part is that you need to talk to your CFO about a few key topics that will be central to winning them over.

Let’s dig in.
- Generating cash (and by consequence revenue) – the lifeblood of any company, cash, is a top priority for CFOs. A strong DevOps program can tie directly to generating cash for an organization. Here are some examples of how DevOps can help in this area:
o   New products come out to market quicker and more tightly aligned to customer needs. Translation: revenue comes quicker from new products because they are more on the mark.

o   Products are more stable which means that there are fewer customer issues and less downtime. If the organization is subject to an SLA, there should be less money going back to customers. If they aren’t subject to an SLA, with a more stable product, customers are less likely to churn.

o   Back-office systems such as billing and provisioning will have better uptime and reliability. Fewer errors means that there is less churn and more opportunities to sell happy customers more products and services.
- Reducing expenses – the other half of the equation for a CFO is how to keep costs down. DevOps can be a huge win in this area. A fundamental tenet of DevOps is automation. By automating rote tasks, your team can accomplish more. They don’t need to hire more people and/or they can take on more projects. Either way, it is a significant opportunity for IT organizations to do more with less by having resources better aligned on the most critical problems. IT organization should walk CFOs through how investments in automation can pay off.
- Growth – for CFOs, it’s not just about managing the revenue and the costs, it’s also about how the company is going to grow. How can DevOps help a business grow? Growth comes from the increased sales of existing products/services and/or the introduction of new solutions. Building a better product is core to the DevOps mission. In my opinion, the definition of DevOps is actually the increased probability that you will find product/market fit. This means, if you can quickly iterate to find what customers need, you will sell more of it. By building DevOps into your organization, you will also find what customers need so you can introduce new solutions as well.
- Long-term stability – CFOs tend to feel more comfortable with long-term stability solutions. Part of the mission of DevOps is to increase stability of the product and infrastructure. By turning around quick iterations, product solutions should continually be more reliable as well. If the product performs well, customers rely on it. The result? Loyal customer bases and steadier revenue streams. Another aspect of long-term stability is predictability of resources and expenses. DevOps can drive that predictability by closely tying demand for solutions to the expenses. A DevOps program can deliver on a regular cadence of product which can translate into increased visibility and stability for organizations.
The conversation with a CFO about why an organization should invest in DevOps is crucial. If IT leaders can have that conversation using a CFO’s key concerns, then the outcome is very likely to be more positive. Our suggestion is incorporate the four key concerns CFOs have – cash, expenses, growth, and stability – into the conversation.
October 14, 2014
Electric Cloud’s ship.io tackles mobile continuous delivery

As increasingly more organizations run into unique challenges around extending the continuous delivery development model to mobile applications, vendors are coming out of the woodwork to start helping organizations revamp their mobile build and test infrastructures accordingly. This week, Electric Cloud tossed its hat into the ring with the beta release of ship.io, a new SaaS service that it’s launching to help users build, test and deploy native iOS and Android apps.

In spite of the fast-paced demands of the mobile marketplace, according to studies from Forrester, 64 percent of organizations release mobile apps four or fewer times per year per device. Many organizations struggle with the fragmented nature of the mobile device and operating system landscape, which can make testing a nightmare.

“Testing typically needs to cover hundreds of different devices operating across multiple mobile platforms, including mobile devices that are no longer being sold or even supported but that are stil used in the marketplace,” writes Mark Buenen, an expert in managed testing services for consulting firm Capgemini.

As a result, mobile testing lags significantly, with stats out from Capgemini stating that only approximately 55 percent of organizations test their mobile apps.
At the same time, commercial app store demands for testing prior to release raises the stakes even higher for testing, as a buggy release could take days to fix due to the time it takes for app store approval. In just those few short days, negative reviews about the bugs could scuttle the app’s future success. And within the enterprise, mobile apps are gaining importance as mobile applications gain a higher profile within core business processes.

“Mobile app development is increasingly important to a growing range of organizations, and it represents a challenge due to the range of operating systems and devices that each application must support,” said Steve Brodie, CEO for Electric Cloud.

Ship.io automatically detects and configures iOS and Android dev projects to simplify the process of creating code across multiple operating systems, versions and device screen densities. Made possible by the acquisition of intellectual property from AngelPad-backed Cisimple, an early start-up in the mobile continuous delivery space, the service is powered by integrations with GitHub, BitBucket and other Git repositories. Similarly, ship.io centralizes the automation of testing and distribution through integrations with AppThwack, HockeyApp and TestFlight. These capabilities are all condensed into a centralized management platform meant to offer a dashboard into build and test status levels across all apps and development platforms.

The ship.io release is a logical extension of services for Electric Cloud, which already focusing on automating processes for continuous delivery within the enterprise. Last week the company released a new version of its ElectricFlow Deploy product, which now, among other features, automatically detects the differences between what’s about to be deployed and what is already in an environment so that only the changed code is deployed in order to reduce risk and deployment time.

While products like ship.io could stand to make DevOps teams more effective in bringing continuous delivery to their development and deployment of mobile applications, process will still play a huge role. According to Capgemini, in its annual World Quality Report focusing on testing trends, its study showed there was a marked shift in worry about mobile testing challenges from previously lacking tools to do a good job to now lacking appropriate testing processes and methods, which 56 percent of organizations stated as a stumbling block. Similarly, lack of mobile testing expertise was named by 48 percent of organizations as one of the biggest challenges.

October 13, 2014
Task Organization for Enterprise DevOps

In 2007 I served as a captain in the U.S. Army during a 15-month tour in support of the “Surge” in Iraq. I deployed with the 4^th Stryker Brigade Combat Team to Baqubah, where our unit’s mission was, literally, to neutralize Al Qaeda in Iraq and unseat them from their position of consolidated power, in order to deny them the ability to influence events in the capital of Baghdad. You wear many hats during a combat deployment, but my primary roles were that of lead planner and battalion Fire Support Officer (FSO).

As a planner I formulated the maneuver strategy and led the battle staff’s planning efforts in over a dozen battalion-sized operations, and over 30 company operations. Once the planning was complete, I would switch hats and go out on mission as FSO, responsible for integrating all manner of indirect fires to support the ground commander’s fight. This came mostly in the form of calling in airstrikes on targets ranging from suspected deep-buried improvised explosive devices (IEDs) to high-level meetings of Al Qaeda leadership.

I have since transitioned into the private sector and the world of software, and am constantly amazed by how many shared concepts exist between the military and business, particularly in the areas of strategy, project management, and operations. Having said that, there is one concept I found to be extremely powerful in planning military operations which seems to have no civilian counterpart, and may be useful in the discussion on implementing DevOps in the enterprise. It is the concept of “Task Organization.”

Army doctrine defines task organization as “the process of allocating available assets to subordinate commanders and establishing their command and support relationships.”

I know, I know. Right now you’re sitting in rapt jubilation over reading that statement, thinking to yourself, “What the heck is this goober talking about, and what does any of it have to do with software?!?” Stick with me for a minute – I’ll get you there.

Military operations are mission-oriented, and by their very nature extremely dynamic and fluid situations. Task organization is a construct to assist commanders in choosing the right “tools” to accomplish the mission. Back in the homeland, units are homogeneous to facilitate training and administration. But when deployed, units become heterogeneous as commanders mix and match capabilities, forcing collaboration among disparate skill sets in order to achieve a common goal – in military parlance, this is known as the “combined arms fight.” This is how task organization relates to DevOps.

To illustrate, consider the following real-world example. In 2007 my unit’s area of operations (AO) was nestled right in the Fertile Crescent, dominated by irrigated farmland with villages scattered throughout, and a handful of urban centers. Many of those villages had never seen Coalition Forces before, but it was my commander’s intent to visit each, link up with the leadership, assess the security situation, and provide any help that we could. The gambit was intended to co-opt and partner with the local populace to root out terrorist cells.

However, at the time Al Qaeda was very adept at placing IEDs on highly trafficked routes to disrupt our freedom of maneuver, making it extremely risky for us to conduct vehicle movement. Like Waterfall, it was difficult for us to go anywhere due to the extra time, effort, and resources required to travel safely. We simply would not have been able to reach every village in our AO using this method.

To combat this deadly tactic, we first took a look at our task organization and asked ourselves, “What combination of capabilities will give us the most advantage and the least risk in achieving our stated goals?” Actually, we used a lot more swear words when speaking to each other, but I’m paraphrasing to keep this thing PG. After our analysis, we decided the best course of action was to take to the skies, by requesting and task organizing a unit of Blackhawks under our headquarters. We reverted to old-school air assault tactics, delivering units by helicopter – and completely circumvented the deadly IEDs Al Qaeda had laid out for us. Goal achieved – this method worked wonderfully, and the locals were so appreciative of receiving some support that they partnered with us in the fight against Al Qaeda.

Incidentally, it was during this time that I invented a new method for bomb disposal. Our dismounted patrols would travel with an Explosive Ordnance Disposal team (again, task org), but the EOD guys could only hump so much C-4 in their rucks, and there were more IEDs scattered throughout than they could dispose of. Having acquired a lot of experience dropping JDAMs, I knew how deadly accurate they were, and suggested that when they found a bomb buried in the road, I could detonate it by dropping another bomb on top of it. This method worked so well that I started to joke that I’d figure out how to open a can of soda with a JDAM by the end of the tour – again using a lot of swear words. But I digress…

That’s what DevOps is about – not cussing, but collaboration. By discussing our problems with units who had completely different capabilities, we were able to find new and innovative solutions to our problems together. We were able to turn a perceived weakness into a strength, and gained additional speed and agility by using air assault tactics.

Imagine for a minute that the Blackhawk unit in this example is like IT operations – they were responsible for providing the infrastructure and capability to deliver our “application” to the correct “market segment” in a timely manner, so that the “business” could achieve its desired objectives. The dismounted patrol is like the development organization, translating “business requirements” into tactics on the ground. By collaborating together, we were able to refine our process over multiple iterations so that we could Continuously Deliver combat power anywhere on the battlefield, at any time and place of our choosing. This also enabled a sustainable advantage over our “competitors,” allowing us to beat them to market time and again.

Gene Kim offers two DevOps patterns which dovetail nicely with the concept of task organization – embedding development in operations, and embedding operations in development. By task organizing an individual or team from operations into development, operations becomes aware of proposed changes before they come down the pipe, allowing them to better prepare to support those changes. By task organizing a section from development into operations, developers become more aware of the effects of their changes on downstream environments, and can adjust their code or provide more information to make the lives of operations easier.

For those exploring DevOps in the enterprise, I’d suggest an exercise in task organization before you begin implementation. What capabilities and skill sets do you have available to you? What can you request from “higher?” How can you mix and match these capabilities to achieve your stated objectives with the most expedience and the least amount of waste? After you’ve mixed capabilities, who will report to whom, and how will they be supported?

And don’t forget to use a lot of swear words.

About the Author

Rex Morrow is the Marketing Director at Datical, an enterprise software company whose solution, Datical DB, manages and simplifies database schema change management in support of complex, high velocity application releases across any environment, for any database. Prior to Datical, he co-founded Texas Venture Labs, a startup accelerator at the University of Texas, and received his MBA from the McCombs School of Business. Before graduate school, Rex served as a Company Commander in the U.S. Army in the rank of Captain, and was awarded two bronze stars during combat deployments in Iraq. Website: http://www.datical.com/ Twitter: @Datical Linkedin: https://www.linkedin.com/company/datical

October 10, 2014
devopsy.kinsta.cloud Examines DevOps-as-a-Service

Should enterprises buy DevOps or build their own? devopsy.kinsta.cloud looks at the benefits and detractors of DevOps-as-a-Service.

To -As-A-Service or Not To -As-A-Service

Vendors are moving enterprise technologies to the cloud, adding “–as-a-Service” at the end of their titles. Such was the case when Disaster Recovery became Disaster-Recovery-as-a-Service. But not everything that can be done should be. Some say that DevOps-as-a-Service is a good example.

“If DevOps is a growth engine for your company, then outsourcing it is like building a car with the motor located elsewhere,” says Michael Riley, Co-Founder, Boxter http://contentboxter.com. Optimizing DevOps requires tight integration between differing and complex entities. If a service can wrap this system into an external package for an enterprise, then either that customer doesn’t have a real need for DevOps or this approach is going to hurt the business, concludes Riley.

But TriNimbus is forming partnerships rather than selling packages. The DevOps-as-a-Service provider educates enterprise customers, brainstorms with them, and develops a shared vision of DevOps, according to Goran Kimovski, Principal Cloud Architect, TriNimbus http://www.trinimbus.com/. The final product is external to the enterprise in varying degrees, depending on the customer’s comfort level and expertise.

TriNimbus’ Take on DevOps

On the process side, TriNimbus takes the stance that DevOps is not primarily about continuous deployment. “The way we see it, DevOps encompasses many aspects including performance monitoring, management, and being able to recognize anomalies and patterns,” says Kimovski. DevOps includes solid backup and restore and disaster recovery processes for all aspects of the deployment. “We essentially try to match requirements with processes,” says Kimovski.

On the tooling side of DevOps, TriNimbus introduces automation tooling, different services that support automated deployment, and the implementation of automated workflows. The enterprise may have homegrown tools or be running continuous integration. “We try to architect a solution that involves the tools that they are already using and take advantage of those by using the skillsets that exist in their organization. So, we architect a solution that is going to scale and that we can maintain,” says Kimovski.

But taking these kinds of home grown tools, services, and workflows into the cloud with a DevOps-as-a-Service provider is risky. “It can sound like a cost effective solution, but end up killing your company’s growth in the long run. You are taking critical infrastructure and handing it over to a third party. If they care more about your business’s growth than you do, then you have a whole other problem to solve,” says Riley.

Software Development Expertise

Creating DevOps-as-a-Service requires expertise in software development. “Our background is software development,” says Kimovski. TriNimbus uses solutions architects and software engineers with 10 to 15 years of experience. TriNimbus has a background in continuous integration and build and release management.

TriNimbus’ experience enables it to work with the customer to break down barriers. In one instance, the customer’s obstacle is patching. “We have a current project that we are working with a client. It’s fairly complex. Each key area has its own piece of infrastructure. Patching it all together is a problem of integration and registration,” says Kimovski. It’s not a single problem of pushing a build onto a machine. TriNimbus built an orchestration workflow that patches things individually and supports rolling patches back if anything goes wrong.

The Cloud Advantage

TriNimbus uses the cloud (Amazon’s AWS http://aws.amazon.com/) to give developers greater access to provision things like compute and storage. “AWS as a software arm seems to understand the need for embedding tools into the platform itself,” says Kimovski. Developers may want to increase the frequency of automated testing. They may want to do load testing. TriNimbus works with developers to enable them to clone a production environment to do that.

But simply cloning a production environment in the cloud for automated testing using a DevOps-as-a-Service provider is more complex than it sounds and carries some concerns. “Cloning a production environment for testing can help you solve problems, but does not help you create a production environment in the first place. It could also cause problems if it’s not directly comparable for performance,” says Riley.

Increasing Release Frequency

Though continuous deployment isn’t the only thing DevOps has to offer, an increase in release frequency is something most TriNimbus customers want. But even TriNimbus admits there are no guarantees. “Just because we have the tooling automation in place doesn’t mean that magically things will start to happen faster,” says Kimovski. A lot of it has to do with being able to test more frequently and get confidence sooner that what the customer has built so far is not going to break things. As a tool in the right hands, that can raise release frequency.

October 9, 2014
Q&A: Gene Kim on the pain of accruing technical debt

Last week, we ran the story Paying Down Technical Debt. This week, we’re discussing that very topic with Gene Kim (@realgenekim). As a follower of DevOps trends, you probably are already aware of his most recent book project, The DevOps Cookbook, and most certainly his previous works, The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.

Gene also founded the security firm Tripwire and was the CTO there for 13 years. Gene has made a career of studying high performance companies and we’re please he took the time to share with us his thoughts on technical debt.

devopsy.kinsta.cloud: Tell us what has been keeping Gene Kim busy lately?

Gene: There is a lot going on. Right now, I’m very concentrated on the DevOps Enterprise Summit taking place in San Francisco October 21 through October 23. The summit will focus on Lean IT, DevOps, and Continuous Delivery. We’re pretty excited about it. We have 50 speakers from large enterprises such as GE, Disney, and Macy’s, and other incredible speakers.

devopsy.kinsta.cloud: Sounds like a great event, Gene. I’m curious to get your thoughts on technical debt. Some people argue that it doesn’t exist. Others contend that it does. Does technical debt exist, and if so how do you define it?

Gene: There is a great definition of technical debt that was given by Ward Cunningham: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

My simple take on that quote is that technical debt is what you feel the next time you want to make a change. It accrues from not only all the shortcuts you make in a project when it’s rushed, but even every time the developers don’t write an automated test – every time that you don’t do data code analysis. When you skip these things, the debt builds up every day. It’s basically all the variants, from the right way to do things versus the way we actually do things. The more of those that accumulate create this ever-increasing amount of technical debt.

devopsy.kinsta.cloud: What does technical debt commonly look like in an enterprise?

Gene: Randy Shoup gave a great talk on this, The Virtuous Cycle of Velocity: What I Learned About Going Fast at eBay and Google, at FlowCon San Francisco 2013, when he was CTO at KIXEYE. In that talk, Shoup provided the countermeasure to technical debt. He stated that any sort of thing that affected performance and quality, as defined by reliability of scaling, was treated as a priority zero defect.

Essentially, what he’s saying is whenever there’s a reliability or a scaling issue, it’s treated as a priority zero defect. In other words, it is as bad as a site down issue. What it means is that it’s like Toyota and when they have a serious issue, everyone stops work in order to swarm the problem until it is resolved. If they can contribute to helping the problem, they do. This is the opposite of what happens in most organizations, where it’s “never my problem” and when technical debt is allowed to accrue. Where you put problems on to the defect backlog, you put it into the security remediation queue, but it will never get done.

It goes there to die. It’s the landfill of good ideas that never get implemented. What Randy Shoup tells is that investing pays off. I would say that’s exactly the culture that enables high performance. High performance is where you’re getting 30 or fewer code deploys, very short lead times, high success rates when they deploy, and short lead time to prepare. That’s as true for operations as it is for information security.

So, technical debt is bad for ops; it’s bad for security. It’s also bad for development, because it slows down future flow.

Shoup nails the difference between the virtuous versus the vicious cycle. The virtuous cycle is described as one having a solid testing cycle. You have good testing so you have a solid foundation, which lets you be more confident. This lets you go faster and faster. The vicious cycle is you don’t have testing. You have a very shaky foundation. You’re afraid to make changes. And you go slower and slower.

devopsy.kinsta.cloud: In your experience of watching high performance organizations, what is the challenge of getting from the slide that discussed the vicious cycle and the technical debt world to one with the virtuous cycle? How do you implement what’s detailed on slide 13, I think it is?

Gene: It really is policy. We have to have a policy that elevates paying down technical debt and enables teams to focus on the nonfunctional requirements – a policy that one’s definition of done is whenever the developer says it’s done, then it’s done. It’s not done until there’s an automated test, an automatic deployment process, so that anyone can push the button and it goes through the test cycle and gets deployed into production.

Deliverables also have to operate in production as designed. That’s a good definition of done. That prevents us from going from sprint to sprint and accumulating technical debt behind us. I would say the countermeasure to technical debt is the right definition of done. It’s like in the agile philosophy quote: The definition of done is at the end of each sprint interval we have working and potentially shippable code.

I would add that it is integrated into chunks. There’s a checking depository. There’s automated testing that anybody can run before the code can be deployed. I think these are good countermeasures.

devopsy.kinsta.cloud: That’s excellent. Now, to get from the vicious to the virtuous cycle, I imagine it takes significant investment upfront before the payoff?

Gene: Unfortunately, this is one of those things where you go slower before you can go faster. But the benefits are so compelling. We know that high performers are doing 30 times more frequent code deployments, and they can do them 8,000 times faster. That’s 8,000 times faster. So the payoff is huge.

Think about it: If you’re not doing a deploy a day, that means that you are 100 to 1,000 times slower than high performers. High performers can execute a deployment in minutes or hours, whereas lower performers need weeks, months, or quarters. Of course, we have to take investment to go from weeks, months, and quarters to on-demand, executing within minutes. But the value of doing that is too high to ignore.

October 7, 2014
Targeting software development to SoCs / NoCs using a DevOps approach

Without hardware to run it, software is useless. Hardware influences software development, since the software must fit the hardware platform and take advantage of its strengths, abilities, and components. Network-on-Chip / System-on-Chip hardware is a relatively new platform enabling communications between network and system elements that exist on the chip at the molecular level. This is a fascinating area. Learning to target software development for the NoC / SoC platforms using DevOps approaches should prove equally enthralling.

The Top Three Keys to a DevOps Approach to Developing Software to an NoC / SoC Platform

According to Aaron Cois, Researcher, the Software Engineering Institute, Carnegie Mellon University, the top three keys to a DevOps approach to software development for NoCs and SoCs are as follows. First, nurture a collaborative culture where collaboration between the parties involved in the software development process can flourish. Second, leverage Infrastructure as Code (e.g. simulation of hardware, EDA or ECAD applications, and programmable environmental configurations). Third, use automated creation / testing components for both hardware and software to create a fully automated DevOps pipeline.

The enterprise must foster equal collaboration and engagement among the necessary participants. “Getting technical staff with specific areas of expertise (Dev, Ops, Security) fully engaged in the project from the beginning ensures that their respective areas of expertise are first-class concerns in all system design and implementation decisions,” says Cois. This is correlates with Conway’s Law, which states that “two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily shows congruence with the social structure of the organization that produced it” (http://www.melconway.com/Home/Conways_Law.html).

Therefore, says Cois, a team of software developers will design a system primarily to meet software development concerns (features, performance). A team that also contains IT Ops professionals will design a system that also meets operational needs (deployment, maintenance). A team that also has Information Security professionals will produce a system designed to address security concerns. “All team members have to be equally tasked, engaged, and accountable for the project, however, for this effect to work,” says Cois; “this is where organizations commonly fail.” In real-world scenarios, tasking is unequal such as when IT operations attends a few meetings to consult, but the primary project team is made up entirely of developers. Or, in another example, InfoSec does a system audit before release and identifies issues that development should fix, but because InfoSec wasn’t strongly involved in the system inception and design, development may never complete the fixes.

The enterprise must focus simulation techniques on the development process. “Simulation and mocking are integral in situations where you are developing custom hardware as part of the overall process. This is the case with SoC/NoC systems,” says Cois. By simulating the chip hardware, developers can script/automate a number of things:

1) Testing hardware configurations
2) Testing hardware interfaces to software systems
3) Testing software/firmware deployment onto hardware
4) Security concerns
5) Possible networking scenarios on NoC chips
6) Other quality attributes such as response time and load testing

“Simulating the hardware platforms enables the development team to perform the same automated/continuous deployment techniques that are common to DevOps in general on SoC/NoC development projects as well,” says Cois. This gives developers advantages such as the ability to automatically deploy the system multiple times per day, which builds confidence in deployment success (through repetition). As with all automated deployment scenarios, the parity between the internal deployment platform (the hardware simulation) and the production deployment platform (real hardware) defines how much confidence development gains from repetitive deployment (e.g., if the simulation isn’t accurate, you won’t be very certain deployment will work on real hardware).

Challenges & Solutions

There are challenges to developing SoC/NoC software the DevOps way. First, the organizational culture needs to change so that communication and collaboration between various areas of expertise can dramatically increase. This is difficult. According to Cois, the solution is to hire generalists who are T-shaped professionals with a wide T. “They will have their specialty (Dev, Ops, Sec) and an understanding of other project needs. This understanding leads to empathy and effective collaboration–to the benefit of the project,” says Cois.

The second challenge lies in adopting automation, which is a significant technical shift, especially on legacy systems. It requires planning and technical expertise. “Knowing your goals before you start is key–a lot of organizations may jump into implementing automation without knowing the benefits they expect to see–or how to measure them,” says Cois.

October 6, 2014
Monitor mobile apps behavior with freemium tool from AppDynamics

One of the core elements of DevOps is rapid development. Organizations remove obstacles, and function more efficiently to compress timeframes and evolve in real time. In order to be more effective, though, you also need to have real-time feedback on the existing app experience so you can adapt on the fly. AppDynamics wants to provide that with a new self-service freemium version of its Mobile Real-User Monitoring (RUM) platform.

Free mobile crash analytics puts powerful data into the hands of mobile app developers who want to understand the critical failures that drive users away from their app and damage credibility, whether it’s the latest game or a business enterprise app. AppDynamics Mobile RUM enables mobile developers to quickly identify unique and recurring crashes for specific devices, operating systems, or carrier types, and fix them before they become pervasive.

“If you don’t know what your mobile users are doing or know at what point and why your mobile app is crashing, you’re essentially flying blind in the brave new mobile world. With millions of apps available on the Apple and Android app stores, customers have little patience for a poor mobile experience. Not only does the poor mobile app hurt revenues, but it also hurts brand perception” said Jyoti Bansal, founder and CEO of AppDynamics in a press release statement. “With such rich mobile app performance management capabilities available in the market today, there is no reason businesses should leave their brand experience to chance. With free mobile crash analytics, you can quickly pinpoint the causes of mobile crashes and get them fixed before your users defect in droves.”

AppDynamics launched a free, self-service, 15-day trial of the full-featured version of the enhanced mobile RUM product today. After the 15 days expires the full-featured professional version converts to a limited functionality lite version and continues to provide users with valuable mobile crash analytics data entirely free, forever. The freemium offering provides the crash analytics capabilities for free, with data retention for a 365-day period. Mobile developers can flashback up to a year to learn from historical trends and patterns.

The full-featured professional version includes a variety of additional features and capabilities, like mobile business transaction correlation, enhanced mobile end-user experience management, and mobile behavior analytics. AppDynamics Mobile RUM can be deployed locally on-premise, or as a SaaS (Software-as-a-Service) offering.

Bansal added, “Mobile is an essential component for software-defined businesses. That’s why it’s an essential component of the AppDynamics Application Intelligence platform as well. AppDynamics enables customers to move seamlessly from mobile data to server data, from smartphone to PC, so they have command of performance and reap actionable intelligence at every level.”

You can use the lite version, and leverage the benefits of free mobile app crash analytics forever. If you want the features and capabilities of the more comprehensive professional version, AppDynamics Mobile Real User Monitoring costs $3,000 per year for every 5,000 monthly active users.

Whether or not the feature in the professional version are worth the cost for your organization, it’s hard to argue with free. If you develop mobile apps, you should at least take a look at the data that AppDynamics Mobile RUM can provide, and determine whether or not it can be an asset that helps you adapt and evolve your mobile app experience to maintain your brand reputation and retain loyal customers.

October 1, 2014
DevOps and Infor’s Journey to the Cloud

Infor, a leading provider of micro-vertical application suites, has introduced DevOps as part of an initiative to migrate its enterprise application suites to a cloud platform. The significance of this should not be lost. Infor is not a young, Web 2.0 unicorn that was born with DevOps DNA.   Infor is a 14 year old privately held software supplier with over 70,000 customers across multiple micro-vertical markets. Infor’s industry-specific applications are mostly deployed and managed on-premise. The move to a cloud based AWS platform is as much of a paradigm shift for Infor as it is for its diverse customer base.

Infor Labs Journey to the Cloud

Infor’s leadership team launched the company’s annual user conference last week with keynote details about Infor XI’s cloud strategy and partnership with Amazon Web Services.   CEO Charles Phillips explained the reasoning behind the move while COO Pam Murphy recounted the technical efforts behind the scenes. Both acknowledged the necessity of creating a function that would be dedicated to cloud operations. Standing in front of thousands of customers, Ms. Murphy described Infor Labs and how its DevOps practices would ensure that the right operating procedures were inserted into the development lifecycle. According to Ms. Murphy,   DevOps would bring “fully automated hands-free cloud operations that improves efficiency, effectiveness, consistency and security while reducing manpower requirements. “

Infor’s recognition of DevOps as a critical business success factor for its next generation of industry suites is impressive. Brian Rose, Senior Vice President of Infor Labs and a key member of Infor’s management team for the past nine years provided some insight. “The motivation behind developing and growing the DevOps team was driven by our ‘Cloud First’ strategy. Over the last 18 months, Infor underwent a significant transformation to deliver industry solutions in the cloud. This required development teams to gain a new understanding of the technical operations so that our products operate optimally and cost effectively in the cloud.”

“Our DevOps team worked closely with the development and cloud operations teams to develop standards for the cloud. Further, they were responsible for setting and maintaining the cloud standards including the development of architectural components that allowed for the automation of provisioning, patch processing, upgrades, backups, restores, monitoring and the development of a portal to provide a self-service option for these functions,” Rose explains.

Infor Labs has already seen results from DevOps. “The benefits that we have experienced include the reduction of the provisioning of an industry suite from weeks to minutes, decreased implementation time and costs for our customers, and solutions that are optimized from a technical ops perspective that allow our cloud infrastructure to scale so that we can support the thousands of customers that we have today in the cloud and the ability to scale to support the thousands more that we see moving to the cloud in the future, ” says Rose.

While DevOps is not intended solely for applications in the cloud, software providers such as Infor that publicly promote the value of their own DevOps culture increase proof of concept while serving as role models for their enterprise customers.   If the primary objective of DevOps is to improve speed to market and time to value, who better than a trusted commercial software provider to demonstrate real world insight and results.

September 25, 2014
Top 3 Must-Haves in Development/IT Operations Project Handoffs, Part Two
As you may recall, in part one we uncovered 1.5 of the top three must-haves in development/IT operations project handoffs. We now know that operations really needs to know what the normal and abnormal operating conditions are for any software that development produces. We know that development needs to share the accumulated technical debt for that software as well. And we had just begun to understand the role that Big-O Notation plays. If you have not read part one, you may want to do that first. Now here we go with part two.

Here is an example of O(n). Given the goal of computing the sum of all elements in an integer array, for example, the algorithm would work like this: start with the first element, add the second, add the third, etc. In Big O Notation, this is O(n), which is linear, i.e. adding one element means executing an additional step in the algorithm.

Here is an example of O(log n). Given the goal of finding a particular value in a sorted array of integers, the binary search algorithm would work like this:
1. Find the middle element and check to see whether it is the value you are looking for. If it is, return it.
2. If the middle element is bigger than the searched value, continue with step 1 over the first half of the array.
3. If the middle element is smaller than the searched value, continue with step 1 over the second half of the array.
In Big O notation, this is O(log n), which represents logarithmic complexity, i.e. adding one element will (usually) not increase the number of steps, but adding K elements will add one step.

There are many types of algorithms that fall in different groups of Big O notations. The general rule of thumb is:

O(log n) < O(n) < O(n log n) < O(n^2) < O(n^3)

So, if for example operations knows that the algorithmic performance of a software component is O(n) (expected linear performance), but it behaves like O(n^2) (quadratic, i.e. adding one element exponentially increases the operations needed for processing) they will realize that there is something wrong from an operational perspective.

“I would like to have that information because it helps me do capacity planning, it helps me understand dependencies and intricacies, it helps me do my job in an optimal way (no need to get that expensive 10G network controller if our current implementation is unable to hit 1Gbps),” says Vachkov.

Number Three Must-Have: The Architectural Diagrams for the Overall System and Its Components

“This is somewhat understood and followed. However, the diagrams and documentation are not usually comprehensive enough, if at all comprehensive,” says Vachkov. Many operations people have a deep understanding of the software development lifecycle. They need to know the inner-workings of software components to properly design reaction procedures, dependency checks or checklists, and run-books.

Here are some examples. In many environments, operations personnel will develop their internal procedures in the form:

If you see A -> do X
If you see A, but B -> do Y

This applies to reaction procedures, scripts, and runbooks, according to Vachkov.

Dependency lists are a bit more complex, sometimes called checklists. These have the form:

if you need to do A then:
-> check if AA
-> check if BB
-> check if CC
-> do X

“These can be complex and cover different areas, from installation of software components to deployments of new tenants in multi-tenant systems to troubleshooting and post-mortem analysis,” says Vachkov.

“When this kind of information is lacking, the software is a black box. Being a black box is bad for operations. I need to know that the software expects to find a MySQL server on the same host (because it only uses a UNIX socket to communicate with it) and I should not need to figure this out on launch day,” says Vachkov.

Extra Pointer!

“Very big Bonus Point to all developers who keep lists of all the hidden knobs and switches that operations can use in run-time to deal with a particular failure or abnormal scenario,” says Vachkov.
September 24, 2014
Paying Down Technical Debt

When watching IT shops over the years it seems some, despite trying to cram two weeks worth of work into six days a week, never seem to move very far forward. And yet other teams seem to make tremendous strides in productivity and outcomes despite not working as many hours as the poorer performing organizations.

Why is this? Like many aspects of life and business, it’s about working smarter, not harder. When it comes to enterprise IT that often means avoiding technical debt. The generation of demand for work to fix issues that should have, could have, been avoided had the work been completed properly the first time. “In an engineering context, I believe we are talking about the negative side of the tradeoff ledger,” says Kevin Behr, the chief science officer for the CXO and Board Advisory Practice at Praxis Flow. “Engineering inherently involves trade offs between what we would like to do and what we can actually do, so we often cut corners in the name of expediency,” Behr says.

Aater Suleman, co-founder and CEO of Flux7 put it another way: “It’s when you have urgency that takes precedence over the right thing to do. In that rush, you’re not making decisions the right way, you’re just getting things done really quickly in the heat of the moment. And you have to go back and fix those later,” Suleman says.

The high cost of technical debt
How much technical debt does your organization have? How much latent work is hiding in rework and hurdles that need to be leaped because of shortcuts taken and ongoing bad decisions made in design, infrastructure, and operations. How much debt has been accumulated today, this week, month, or year? And, more importantly: how do you pay down that debt and not accumulate new debts in the future?

According to Donnie Berkholz, an analyst at Redmonk, DevOps relates to technical debt in that DevOps is a more collaborative approach to software development and enables the people building and running the software to have a fuller understanding of all the places technical debt can live. “Sometimes it’s not directly in the code base but rather in the release tooling, or the production systems,” he says.

An example Berkholz cites as a n example of the potential cost of technical debt is Knight Capital’s $460 million loss due to lack of documentation and automation of their server configuration.

Paying debt down
As a way to help reduce technical debt, Berkholz advises enterprises consider running “blameless postmortems” after outages or issues. “It’s about explicit acknowledgment of the facts as well as setting aside time to fix underlying problems without searching for blame,” Berkholz says. “Technical debt won’t fix itself; you need to set aside time and effort to pay it off, without worrying where it came from beyond lowering future debt as much as possible,” he says.

And for avoiding technical debt during ongoing operations, Suleman advises enterprises continuously test their operations and applications. According to Suleman, most companies that have taken on significant amounts of technical debt actually don’t have adequate testing in place. That, by itself, is a challenge itself, but it turns out many organizations actually have another issue – some enterprises hold an unsubstantiated level of faith in their testing. “I’ve seen many companies where they think they have automated testing, and hence, they rely on it. But the testing is not exhaustive or complete enough to actually rely on,” says Suleman.

For instance, Suleman explains, it’s rare that enterprises conduct performance tests on the code they commit. “Which is why performance testing provides a classic example regarding technical debt, because the enterprise can be doing everything right, and adhere to all of the general DevOps methodologies, and yet the application doesn’t run properly because they haven’t tested correctly,” he says.

When balancing the IT ledger, think long term
While it may sound straightforward enough to start testing applications and system changes continuously, and spending a little more time thinking through design issues upfront to avoid trouble later – continuous improvement efforts, such as trimming past technical debts incurred, don’t take root in organizations overnight. It takes time to build these processes in. Think marathon more than sprint. “Continuous Improvement is not as much for the impatient as it is for those willing to invest in steady, long-term activity,” says Behr.

September 23, 2014