devopsy.kinsta.cloud

Author: contributor

The DevOps and Security Manifesto

Early in Illumio’s history, I saw the future of DevOps security. The CISO of an electronics manufacturer brought us in to help secure a new support service that was built entirely in the cloud. After meeting with the security team, we were introduced to the application development team who cast a cold eye on our technology. About five minutes into the demo, the group’s manager asked to take control of the keyboard and start using our software. “I know how to use this. It’s like network-security Chef,” he said with a wry smile. He flew through the UI.

Fast forward to the recent DevOps Connect event at RSA, which underscored the critical importance of cybersecurity to the application development process. If business increasingly relies on agile software development, the lack of corresponding fast-moving security approaches effectively increases the risk of a breach or a cyberattack. You cannot build and mount applications in a distributed application and computing environment and then rely on a static, hierarchical security model built upon chokepoints, infrastructure control points and organizational silos.

Traditionally, one group created applications and another deployed them on the compute infrastructure. Then, a third group implemented security and ensured applications were trusted, particularly through instrumentation of the perimeter network security. Those days are disappearing.

It is time for a new relationship – and new, shared technologies — among DevOps, infrastructure and security, expressed through what I believe are are 10 principles for DevOps and security.

Principle I — No divine right of InfoSec primogeniture. Security must not be run in a silo. While security teams play the most critical role in assessing corporate risk and setting policy, there must be leadership and shared responsibility across various IT functions.

Principle II — Orchestrate but remediate. Security must be as responsive to continuous delivery as application creation and scaling. Application developers need cool, agile tools for security, too.

Principle III — Application developers must not put the organization in harm’s way. They must consider security at the beginning of the application development cycle and not simply hand off the responsibilities to others. Moreover, they must have security capabilities well instrumented into application development tools and infrastructure.

Principle IV — Speed should not kill. Lack of speed hurts business. The spread of malware kills business. The speed of application development should not provide a corresponding acceleration in security risk.

Principle V — Reduce the attack surface. Application developers must co-join with security teams to reduce the attack surface available to bad actors. By considering exposure and risk at the front end of the DevOps cycle, fewer issues should arise afterwards.

Principle VI — Security must be built-in, not bolted on. Application and security architectures that can contain the threats are the order of the enterprise. To Principles IV and V, this increases organizational speed and reduces risk.

Principle VII — Equality of the data center and cloud. Information security must be considered and deployed equally for the data center and the cloud. Separate but equal approaches are not the preferred path for IT professionals. The more widely distributed and deployed applications become, the more unified the security approach must be.

Principle VIII — Stream, not batch. Security must deploy as streaming technology, not batch processes. There is no “set it and forget it” approach for security in a DevOps world.

Principle IX — A minute lost finding a breach is unacceptable. Only a minimal amount of time (second, minutes) must pass in finding cyberattacks and breaches. Systems must be engineered for constant visibility and notification of policy violations.

Principle X — Common Contribution. The maintenance of a strong DevOps security approach requires a shared contribution to application and security approaches toward the common good. The day of IT silos is ending.

About the Author/Alan Cohen

Alan Cohen – As chief commercial officer, Alan leads Illumio’s go-to-market strategy and customer engagement life cycle organizations, including marketing, support, talent, and IT. He is a 25-year technology veteran known for company building and new-market-creation experience. Alan’s prior two companies, Airespace (acquired by Cisco for $450 million) and Nicira (acquired by VMware for $1.26 billion), were the market leaders in centralized WLANs and network virtualization, respectively.

Prior to Nicira, Alan led the enterprise marketing organization at Cisco, a team of 300 responsible for bringing to market an associated $25 billion product portfolio. He serves as an advisor to several technology companies including MobileIron, Highfive, and Netskope. Alan is a frequent industry speaker and commentator whose work has appeared in The New York Times, Fortune, Re/code, and Gigaom. He has a BA from SUNY Buffalo, an MA from the School of International Service at American University, and an MBA in Finance from the Stern School of Business at New York University.

May 20, 2015
Lean Value Stream Mapping for DevOps
Value Stream Mapping is a crucial step in assessing an organization’s DevOps capability. We create a value stream map of the software development lifecycle early in any DevOps engagement, because it helps us to-
- Provide context for our architects and technical experts who are, in parallel, examining tools and technology.
- Establish a performance baseline, against which the improvements delivered by adopting DevOps will be measured. (See my other blog post on Box Scores for more on this).
- Begin the process of winning hearts and minds, and engender cultural change. By working side-by-side in a workshop, Dev and Ops resources, as well as those involved in planning, test scheduling, and other activities, start to gain an understanding of how the work they do is linked to steps upstream and downstream. This lays the groundwork for closer coupling of those activities in the future.
What’s interesting is that the template we use for our DevOps Value Stream Map is almost identical to that which we use for other service processes. It’s been used by IBM Lean Coaches to assess processes as diverse as Marketing Campaign Development, Order-to-Cash, Mortgage Applications, and Production Support to name but a few. This template was evolved from more traditional Value Stream Maps used to capture manufacturing processes, and a slightly different template also exists for innovation or product development processes.

At the start of every Lean project – whether it’s in DevOps, Insurance Claims, New Product Development, or Financial Forecasting, I review the Value Stream Map template. I ask myself and my team if the questions make sense for this process and if the boxes we are seeking to fill are relevant. Some of the language might be slightly different, and the outputs will certainly differ – from a high frequency process where a step takes minutes and seconds, to a creative process where a step could take weeks. But almost without exception, the template remains the same.

We ask the same questions across all these types of processes – and now we ask those questions of the Software Development Lifecycle. Those questions are:
- What activities are being performed?
- Who delivers those activities? How much of their time is dedicated to those activities?
- What is the yield, i.e. ‘right first time’? What % of rework is generated? What causes rework?
- What tools are required to complete the step? And what other inputs are required?
- How many units (e.g. work packages) are ‘work in progress’ within this step?
- How many units are waiting in the ‘inbox’? How will they be prioritized or scheduled? How long will they, typically, wait for?
- How long does the step take? How much of that time is effort, or touch time, versus duration, or in-process lead-time?
When all’s said and done, all Value Stream Maps have something fundamentally common: they are all about flow – and DevOps is no different.

About the Author/ Katie Sotheran

Katie is an IBM Lean Master based out of Los Angeles, California. Katie has many years applying Lean principles to processes as diverse as beverage distribution in Spain, lubricant product development in the Netherlands, Insurance Sales in the UK … and IT operations, all over the world.
May 19, 2015
Why I Dislike The Term ‘DevOps Culture’
Culture is critically important in an organisation. It’s all of the hidden stuff that actually matters. It’s what people value and it feeds through to how people behave when you aren’t watching them, driving thousands of small decisions per day across the enterprise. A broken culture is a horrible thing to work within and a really tough thing to change because it is so inherent to an organisations DNA.

I also believe that DevOps is fundamentally a culture. If people aren’t approaching IT delivery in a collaborative, emphatic way with a focus on continuous improvement then it probably won’t happen despite all of the change initiatives in the world.

On the flip side, we can have the slowest, most beuracractic, most legacy technology environment, but the right culture will usually transcend all of that and make good DevOps like ways of working happen.

With all of this said, I really dislike the term ‘DevOps Culture’. Nothing tends to get me ranting more in the DevOps arena than hearing that phrase.

Why? Because it is so inactionable.

I speak with a lot of enterprises who are looking to adopt DevOps. Once they have decided to get started, the first question is ‘What Shall We Do First?’ If I was to say, ‘DevOps is about a culture and about people having empathy with one another’. They would say ‘Great how do we achieve it? What do we do tomorrow, next week, next month?’

At this point, some people scratch their heads. In the past I’ve heard, ‘buy dev and ops a pizza or some beers – thats a good first step. Maybe try a rotation or two and the culture will develop.’

Personally, I don’t think that will cut it in a 10,000 person globally distributed IT function. The pizza bill alone would bring down the organisation.

Moving Towards A DevOps Culture

Culture is very hard to influence directly, it’s emergent from much more concrete activities.

The meat of the discussion needs to lie there – in the steps we perform to get the outcomes we want. Things like:
- Moving to cross functional teams
- Cross training or hiring people with polyglot skillsets
- Giving people the same incentives across the IT function
- Empowering people to self optimise their processes and the end to delivery lifecycle
- Encouraging people towards cross-silo collaboration over being tied to a rigid process
- Changing reporting lines in the business
- Investing in optimising the path to production over new features
- Training and coaching developers, testers and IT operations on new collaborative ways of working
- Bringing in new tools to support collaboration across siloes
- ….. & 1000 other concrete activities
To me, roadmaps of the activities above and the challenges and subtleties involved in doing them are much more useful than a nebulous statement about DevOps being a culture. I can actually do something with these!

DevOps needs a much more rigorous approach to achieving it within the enterprise. We need to be develop out all of the steps above and bringing the conversation down to earth. Only when we get to this level of detail will we actually succeed in moving the dial to a DevOps culture.
May 18, 2015
Moving from Infrastructure Automation to True DevOps

Deciding on two separate teams, or an integrated end-to-end team

While a lot has been said about “the right way” to do DevOps, what we’re seeing in practice are two different approaches being tried to enable development and operations to work together as a team. On the one hand, there’s the approach to create an end-to-end, integrated development team, which you might call ‘Devops’. On the other, there’s ‘DevOps’, featuring two development teams – one working on application code, with another developing a platform using Infrastructure as Code techniques in a virtualized environment.

DevOps: providing a platform

Perhaps the most obvious way to go is to have a platform team to provide a runtime environment that “just works”, and a separate application team that develops the business logic to run on the platform.

For some organizations, particularly where one of the teams is outsourced, this separation is going to make more sense. You might buy an off-the-shelf product, build your own platform in-house (which seems to be what many organizations are looking to do with Docker right now – warning: it’s harder than it looks!) … or sign up with a PaaS vendor.

Whatever the situation, the platform should be versioned, just like any other piece of software.

This approach can be ideal for developers because they are free to work on code and focus on the business logic, and they really don’t need to worry about how it runs in production. It’s up to the operations team to make sure that the platform is stable and that it delivers what the developers need.

Communication is still key

Even with a physical or organizational separation, the importance of effective dialogue between the two teams cannot be overstated. This won’t work if the relationship is adversarial. There has to be a genuine awareness of common goals. If the operations team doesn’t understand where the development team is going, and what they need from the platform, then there’s going to be trouble. The idea that one platform is going to cater for every development need is often unrealistic, so versioning and the ability to run multiple platform versions side-by-side, or cater for exceptional situations where a particular application might need its own stack, is very important.

There has to be a clearly defined boundary, which should be close to the application code and configuration layer. The application handles the business logic, the platform handles the deployment, logging, monitoring, failover and auto-scaling.

The development team can focus on getting those new features and improvements into the live product, while operations handles the actual roll-out and manages traffic. For this to work, the platform must enable you to quickly determine who is responsible for any problem that crops up. It’s worth investing time in the setup to ensure that errors are explicit, so you don’t waste time tracking them down.

Arguments between the two teams are bad for progress and morale.

Devops: A full stack development team

For some businesses, it’s going to make more sense to put together integrated development teams that work directly on delivering the full stack from a shared code base, from virtual machine to application code. This allows you to design and optimize each system in a way that takes the application’s specific perspective and requirement into account, and can be an especially good fit if your applications differ from each other greatly in terms of the operating systems, middleware, etc., that they run on.

This approach can only work if the overall group is small (Amazon’s “two pizza” teams are a good example) and has sufficient knowledge and experience to see the big picture of the entire system.

It’s not possible for everyone to understand every part of the full stack in detail, but there are areas of overlap where greater collaboration will increase the level of shared knowledge and allow the team to build a better overall system.

Pulling together

The shared foundation of the Devops approach builds mutual respect and enables more free-flowing communication, but it must be based on shared goals and a vision of what the overall purpose of the system is. This integrated approach can give you much more flexibility, but it also means holding the whole team responsible for keeping everything running. Shared code equals shared responsibility.

The right approach

You need to take a baseline, and then put metrics in place to track your progress. You have clear goals in mind and a system to measure them. So how do you find the right approach to achieve those goals?

It would be wrong to say that one approach is better than the other. What you need to do is assess what will work in your organization. Both are means to achieving similar goals, but finding the right approach is about understanding what your company is looking to achieve. You might choose common goals, like reduced expenditure, or reduced error, or you might choose something more specific to your industry. Establish your goals at the outset, and make sure that they’re measurable.

The right approach is going to be the one that gets results for you — that’s why setting up a baseline and metrics is so important. You may find that a hybrid of the two approaches is going to be the right fit, but you aren’t going to know for sure until you have some hard data to back up your expectations.

Be sure to join devopsy.kinsta.cloud editor-in-chief Alan Shimel on Thursday, May 21^st as he hosts the webinar, “Ship Faster without Breaking Everything” to further your smarts on Continuous Delivery.

About the Author/Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

May 14, 2015
The 3 practical change elements in enterprise DevOps

Culture, Technology & Ecosystem

Most enterprises approach DevOps adoption in a singular fashion: they use a bottom-up approach that is typically technology-driven and groups all considerations like, culture, metrics, processes and communication into a single stream of work that is often led and implemented solely by technology-oriented champions.

However, this singular approach presents a few issues:

(1) First, it leads to poor planning on the change aspects of DevOps that are not (and should not be) technology driven – although we (DevOps Evangelists) are not change experts, we believe we can properly assess impact & lead organizational change just because we are the subject matter experts on the technical topic (DevOps). Accordingly, we miss the wider context and relationships with non-IT functions that would be impacted by DevOps.

(2) Second, it naturally focuses the efforts on the areas inside our comfort zone (technical aspects) and potentially disconnects the DevOps program from the Enterprise priorities. If it didn’t, it limits DevOps to a technical change of tools and automation.

(3) Third and most important, it contributes to the absence of realization that the changes in areas outside of IT is critical to the success of DevOps adoption and that specialist (internal or external) help in these areas may be required and better yet, often acts as a catalyst for change.

The consequence of the 3 points above is that post the initial phases, enterprises reach an incomplete point of “DevOps Equilibrium”; this is the state that enterprise IT reaches after installing some automation tools, setting up a basic practice and changing some behaviors. It takes a lot of effort, dedication and pressure on the organization’s DevOps evangelists to make this initial launch and bring the beginnings of DevOps into their Enterprise. By the time they reach that point, energies are depleted, the bigger challenges of enterprise politics and ecosystem become apparent and the thought of another push to bring in more teams, departments, tools and stakeholders on board becomes a burden.

The question then becomes, why is it a struggle and why is it difficult to adopt DevOps in an Enterprise? The reason is that the singular, technology-driven approach that “considers” the soft aspects of DevOps fails to leverage the value it delivers by transforming it into executive sponsorship and political influence; and the reason this happens is because executives consider a bigger enterprise view that stretches outside of their departments and outside of IT but the technology-driven, singular approach has a narrower view and fails to address the ecosystem of the enterprise that surrounds the technology and the culture, and accordingly all the executives’ concerns.

In my experience, one of the main reasons DevOps evangelists in Enterprises fail to move beyond their point of equilibrium is because they approach DevOps as a singular, technology change not as an enterprise change.

What I have seen from multiple enterprise DevOps journeys is that Enterprise DevOps adoption should be broken down to 3 main “Change Elements” and DevOps Evangelists should plan for each “change element” separately under a single program umbrella:

1st Change Element is “Technology” – Enterprise IT landscapes are typically diverse with bespoke and packaged products. Having the technical expertise to understand what DevOps tools fit the enterprise landscape and how to integrate them into bespoke and packaged products is key. Also, understanding what does “implementing DevOps” mean to different IT systems is crucial; for example, do you need to automate the release of revenue-assured systems where speed is not as important as quality or is it enough to implement quality inspections only? Also, which systems do you start your journey with and based on what criteria did you choose these systems/projects?

2nd Change Element is “Culture” – This is looking into how the IT teams would change the way they work, for example, developers need to check-in more frequently, business analysts need to learn to write behavior-driven requirements and operations should start understanding more about what developers do. Another example is how the developers’ (or testers … etc.) objectives will change to become more DevOps-Friendly? (For example, objectives should focus on the handover points between teams rather than team-specific activities). This is more focused on internal IT rather than the rest of the enterprise. Challenges arise here when adoption is phased without change planning – when developers potentially are required to change their approach when testers and operations teams are not. In this scenario, frictions arise.

3rd Change Element is “Ecosystem” – This is the core of the message and it is about how to plan for organizational change outside of IT. This element is about how DevOps impacts the enterprise outside of the IT space and how to position DevOps to the rest of the enterprise. Here are a few examples of what should be done in this space:

(1) Finding a Context: DevOps evangelists need a context for their initiative and it needs to complement other efforts in the organization. For example, evangelists should choose an organizational pain point like “poor customer experience driven by poor product quality”, and position DevOps as the IT solution among a wider enterprise program to tackle the issue – this helps evangelists take a benefits-driven approach to DevOps adoption, which goes along way in navigating the politics of the enterprise.

Another example is the “lean initiative” – in most organizations I’ve seen, there is usually a process improvement or lean initiative going on in non-IT functions; evangelists need to hook into these relevant initiatives, present DevOps as aligned with the organization’s direction of becoming lean and position DevOps as the IT part of that lean journey.

(2) Second, evangelists need to understand and assess the impacts of DevOps outside of IT. For example, as they change the culture by changing developers’ objectives (see above), how does that impact the overall HR strategy of the enterprise that places roles in bands and have a clear definition of a “Star” and how to promote this “Star”? Similar to HR is financial governance: how does a DevOps lifecycle work with the budgeting and financial governance process of large enterprises that releases budgets in gates/phases that are typically not iterative?

Another example is how do evangelists link their DevOps metrics with the wider organization performance KPIs and business objectives? How do evangelists deal with the enterprise’s managed service providers and system integrators who may very well be located oversees and get them to work in a DevOps way without breaking existing contracts?

(3) Finally, evangelists need to understand the political landscape and how to gain IT and non-IT support to their DevOps journey. Activities in this space should address the following questions: how do evangelists gain IT and non-IT Executive sponsorship to get non-IT teams to support their journey?

Answering all of these questions above requires partnerships and help from other non-IT enterprise departments – but how do evangelists build these bridges?

Because of all these Ecosystem challenges, I believe DevOps adoption in the enterprise should be approached as an enterprise change not a technology change. DevOps evangelists should dedicate separate plans for the 3 change elements above under a single DevOps program and they should not be shy of reaching out for non-IT help (external and internal).

In the next few blogs, I will discuss each change element separately. Then I will answer the question that probably most of you are asking by now (continuing with the analogy): So what happens if the enterprise passes this “DevOps Equilibrium” and reaches a point of “DevOps Escape Velocity”? The point when DevOps is an established and acknowledged enterprise standard. What benefits will the enterprise reap? And why isn’t the point of equilibrium enough?

About the author/ Tarek Negm

Tarek is a DevOps and Lean IT enthusiast with a specific interest in the change aspects of the movement. He is a founding partner at Do Consultants where he helps enterprises adopt and realise the business value of DevOps and Lean IT. Before that, Tarek spent his career in global organisations in the UK and Europe working in IT leadership and Technology roles in a wide variety of industries including Telecoms, Financial Services, Hospitality and F&B. Tarek’s experience spans all the technology lifecycle starting with Linux kernel development to Enterprise Architecture and IT Strategy, in addition to IT change where he previously led a global IT transformation program across 5 European countries. Tarek holds an MBA from London Business School focused on change management in technology. Reach him on LinkedIn:

May 14, 2015
Surprise! Broad Agreement on the Definition of DevOps
For the past few years, the conventional wisdom has been that DevOps has no agreed upon definition. Instead, everyone has their own interpretation. However, the conventional wisdom is wrong.

While everyone supplies slightly different words, the same working understanding of DevOps is nearly universal. Our understanding of DevOps goes back to a handful of common touch-points. There is the “CAMS” (Culture, Automation, Measurement and Sharing) acronym popularized by John Willis and Damon Edwards. CAMS has been extended repeatedly – Eveline Oehrlich of Forrester is now discussing CALMSS. Gene Kim offers his “3 Ways” and Patrick Debois has codified “4 Areas”. Allspaw and Hammond had 10 deploys a day, and Etsy made technologists fascinated by a virtual crafts bazaar.

Analysts, authors, industry, and community leaders all agree. The ideas are big and mutually supportive. In short:
- DevOps exists to help the business win
- The scope is broad, but centered on IT
- The foundations are found in Agile and Lean.
- Culture is very important
- Feedback is fuel for innovation
- Automation helps
Why: To help the business win

The most popular DevOps book today is The Phoenix Project, with a subtitle “A Novel about IT, DevOps and Helping Your Business Win”. DevOps is not a navel gazing IT methodology for making IT better for IT. It is focused on how stuff involving the technologists can deliver better results for the business.

As Patrick Debois writes in his excellent post,”DevOps Areas – Codifying devops practices“:

As rightly pointed out by Damon Edwards, devops is not about a technology, devops is about a business problem. The theory of Constraints tells us to optimize the whole and not the individual ‘silos’. For me that whole is the business to customer problem, or in lean speaks, the whole value chain.

At IBM, our definition of DevOps calls out enabling the business to “seize market opportunities”.

Today, technology is critically important to how a wide variety of companies compete. Retailers who neglected e-commerce have gone out of business. Logistics companies like UPS find a competitive edge by creating software to shave miles off delivery routes. In the automotive space, Ford is at tech conferences recruiting companies to write apps for its cars and Tesla’s first fix for their flammable battery problem was an over the air software update.

DevOps is a response to what the IT is experiencing – from a back-office concern that needed to “keep the lights on” to key part in how the business competes every day.

Who: A Broad Scope, beyond development and operations.

Yes, DevOps is a portmanteau that brings development and operations together. Yes, the classic DevOps concern is the Wall of Confusion between development and operations. However, with the focus on business value, the scope must include everyone who is involved in taking an idea through IT to business value.

In recent years, there’s been something of a cottage industry of community leaders and analysts writing, “No, no it really should be Dev_____Ops” where the blank is filled in by their own specialty. Examples: DevQAOps, DevOpsSec, DevSecOps, BizDevOps and of course Bussdevtestqanetsecnetops.

When a Finance department must approve the provisioning of each new test environment, slowing the delivery of new applications by weeks or months, there is a DevOps problem that leaves narrow confines of development and operations. It leaves IT. Patrick’s quote above talks about optimizing the whole value chain. In that post he describes DevOps as being about “collaboration, optimization across the whole organization. Even beyond IT (HR, Finance…) and company borders (Suppliers)”.

Based On: Agile and Lean

In answering why he didn’t support a manifesto for DevOps, Patrick Debois points people back to the Agile manifesto and asks them to reread it more broadly. Agile’s shift towards a faster delivery of software, and focus on the end goals make it a natural spiritual ancestor for DevOps. However, from the perspective of Ops teams, Agile represented the barbarians at the gates. Agile generally took root in development side of the house, enabling it to create something the business wanted faster. But with operations still moving at a pace suited to waterfall, pressures grew and the need for something like DevOps became clear.

Where much of DevOps energy seems to come from its Agile roots, the intellectual side of the movement is more rooted in Lean. It seems no accident that many of the Phoenix Project’s lessons are taught away from the cube farm and instead from the factory floor. While we can intuit that faster feedback is better, and the “continuous” in CI and CD is convenient because it lets us map feedback to fewer changes, it is in the Lean literature where we encounter Little’s Law. It provides the queue theory mathematics supporting the idea that smaller batch sizes supports shorter cycle time. And so Reinertsen’s “The Principals of Product Development Flow: 2nd Generation Lean Production Development” has become popular in DevOps circles and is well cited by Jez Humble in his new Lean Enterprise book.

Culture: Collaboration and Experimentation

The Agile and Lean roots show through in the DevOps culture as well. Lean and Agile are both focused on people first, systems second and heavily cross-train or work in cross-functional teams. They also emphasize continual improvement (kaizen) through approaches like retrospectives.

In DevOps circles, collaboration is preached as an antidote to thinking in siloes which has resulted in antagonism between development and operations. For the systems thinking required to deliver for the business, teamwork is required. Developers make better decisions when they take advantage of operations knowledge (Patrick’s Area 3) and operations does better when application knowledge is embedded with them (Area 4).

The other cultural emphasis is a push towards experimentation, constant learning and improvement. This is Gene Kim’s third way of DevOps. The Lean Startup ideas of Eric Reis permeate the DevOps world. Intuit has made great strides in showing how these approaches work in established companies by running experiments in the midst of tax season resulting in improved business outcomes.

These cultural trends come together in things like blameless postmortems discussed by Etsy and Jake Loomis in Web Operations. When things go wrong, organizations need to understand why and take corrective action. In troubled corporate cultures, the messenger reporting the problem might be shot, and the hunt to assign blame for the problem will begin. Healthy organizations look to learn from failure and try to improve the systems that allowed (or guided) people to make a series of mistakes that lead to the failure.

Feedback: Yes. Lots please!

Experimentation, adaptation and learning tend to do better when there is ample feedback. Otherwise, there is too little to learn from. Developers tend to be more productive as well with rapid feedback. Their thirst to know whether the latest change diminished quality led to the practice of continuous integration and the tools that support CI and continuous delivery. That CD ends up facilitating faster delivery of value to the customer is something of a happy accident.

Amplifying feedback loops is Gene’s “second way“. The “CAMS” concepts of measurement and sharing point to feedback. You gather lots of information, and make sure people see it so they have an opportunity to learn from it. And when Elisabeth Hendrickson presents at DevOps Enterprise 2014, as Cloud Foundry’s Director of Quality Engineering at Pivotal, she describes her job as “to see to the care and feeding of the feedback cycles“.

As expected with a collaborative culture with ample sharing, feedback must cross the traditional silo lines. That means the awesome production monitoring that had lived in Ops land, is radiated back to development. This is “Area 2” in Patrick Debois codification.

Automation: Of course.

The “A” in CAMS is automation. Patrick’s “Area 1” points to continuous delivery techniques, well described by Dave Farley and Jez Humble in their book. A Lean initiative looking at IT will find waste in wait times, errors, and more and move towards automation as a natural result. Feedback craves automated deployment of changes, and automated tests or production monitoring that validates them. Automation is what makes a lot of DevOps possible. It doesn’t make cooperation between development and operations happen, but tensions are reduced when Ops gets out of the business of arguing about the SLA they have with Dev around server provisioning and instead provide Dev a button to press.

DevOps isn’t about automation. Automation is just the natural result of DevOps.

Additional Resources not cited above

DevOps for Dummies – by Sanjeev Sharma

8 Best Practices for DevOps – Ashok Reddy’s overview of the Forrester Report

About the Author/ Eric Minick

Eric Minick is a Technical Evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last ten years helping organizations – large and small – adopt continuous integration, delivery and now –DevOps. He is a frequent speaker on the topic, and co-authored Application Release and Deployment For Dummies.

Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products. Follow him on Twitter at @ericminick.
May 13, 2015
Five areas of software development innovation to watch

Software development has undergone a massive transformation in the last two decades. From the first wave of breakthrough do-it-all PC applications such as Lotus 1-2-3 and Microsoft Office, to the launch of the first iPhone and its all-new “app” category, to the recent release of the iWatch and its projected evolution of apps, developers have never been more in demand to support these new technologies.

In May, my company Gemini Solutions will be celebrating our 10-year anniversary, and we’ve been fortunate to have worked first hand on huge advancements. Our close partnerships with some of the most innovative technology companies have given us firsthand insight into areas of significant change, growth and importance for software engineering.

1. Mobile Keeps on Rolling

The biggest area on the horizon for developers is the increasing prominence of mobile. Active in the mobile space since 2007, we have seen the demand for mobile-focused projects explode in recent years, and anticipate it is only going to get more popular. This space has seen incredible change in just a few short years. iOS app development continues to be the most requested, but we’re seeing a lot of growth in Android as well and expect it to continue to gain prominence as more Android devices enter the market. As Microsoft establishes itself as a platform, its apps will not be as in demand as iOS or Android, but I have a feeling that we’ll see growth for them as well.

2. Be Aware of Wearable Apps

Apps are no longer limited to mobile and are branching out to new devices, such as smart watches and bracelets, as they gain in popularity. There’s been a lot of buzz around Apple’s iWatch and the demand for the device is expected to be huge. We’re already receiving requests for the development of wearable apps so companies can keep up with the technology. Many of the inquiries are consumer-focused at the moment, but are beginning to move into the enterprise as well as these devices have the potential to become a one-stop-shop for both everyday and business uses. In addition, we believe that connected app development is also going to increase sharply in prominence. As these new devices link to mobile phones, tablets and computers the demand for interconnectivity is going to be huge.

3. Functional Programming Making a Comeback

We’ve noticed that the functional programming model is starting to see an increased push again. Scala is very popular for functional programming and is gaining traction with developers. We’ve also noticed people using Scala in conjunction with big data installations. JavaScript is immensely popular right now as well and we’re also seeing increasing use of Angular. This space is constantly changing and we expect to see even more infrastructures appear to offer more variety and choice for development.

4. It’s the Real Thing: The Internet of Things

The Internet of Things is the perfect amalgamation of mobile, embedded and cloud. The Internet of Things is bigger than the Internet of Humans. We’re seeing a lot of intelligent connected devices appearing on the market, and this is only going to accelerate as demand increases. A prime example is the popular internet-based security systems, with web-enabled locks, internet-controlled light and heating/cooling accessibility and the ability to view your home at any time via the device of your choice. Companies continue to make large investments in this space, prompted by the growing popularity of connected devices. We’ve been working with the Internet of Things for several years, but it is still a new frontier in many ways and we’re looking forward to being part of the space as it continues to develop.

5. Making a Big Deal About Big Data

In just a few short years, the hype of Big Data has gone from dream to reality. Everyone has their own interpretations of what Big Data actually means, but don’t let that fool you into thinking it’s a flashy trend; it is here to stay. The cloud is emerging as an increasingly popular way to develop and test new analytics apps and for processing big data outside of the enterprise. Data agility will also become even more central as organizations begin regularly using massive amounts of data, as opposed to just capturing and managing it. The umbrella of big data covers many disparate applications. Being able to analyze massive amounts of data to determine user activities, actions and preferences will be priceless to companies, and is why we will continue to see this space explode in popularity.

The software development space has never been constant or stagnant. Huge advancements and innovative new technologies are continuously appearing to change the game and open up new possibilities. We have been honored to be part of this movement for the past decade to help drive these crucial projects forward. If the past 10 years were any indication, the future of software engineering will be bright, unpredictable and unfathomable. I can’t wait to be there for the next chapter.

About the Author/ Theo Nissim

Theo Nissim, CEO, Gemini Solutions – Theo is a seasoned Silicon Valley technology executive with more than 20 years experience. He has led pre-IPO start-ups, built dozens of technical teams, developed technology strategies and driven innovative products and solutions to market. One of Theo’s many strengths and passions is managing large scale, cross-functional development efforts to high profile product releases. Theo has held executive and management positions with large public companies, Sun Microsystems and Wind River Systems, and served as the Engineering Vice President for VC funded start-ups, Digital Fountain and AdKnowledge.

Theo has a Masters Degree in Computer Engineering from the Technion, Israeli Institute of Technology in Haifa Israel. He lives in Palo Alto, California, with his wife and twin boys.

May 13, 2015
The Great Legacy Code Crisis Of 2016

Over the next few years, I believe that legacy software is going to become a key factor which will start impacting organisations in fundamental ways, having a sudden and significant impact on their profitability.

Those constrained by legacy platforms will be operating with a ball and chain, holding back their ability to get new features to market, to iterate, and to innovate with software.

Those unconstrained will be able to fly by taking advantage of modern tooling and approaches, and quickly grab market share from an increasingly fickle consumer base.

These modern approaches to software delivery such as DevOps, Continuous Delivery, cloud, containers, infrastructure automation and polyglot MicroServices are exponentially better approaches than last generation technology. Those who are working on these modern platforms can move so quickly in comparison to more traditional enterprise environments that people working on older platforms don’t stand a chance. It’s at least a 5-10x uplift in speed of delivery.

What is scary is that by legacy I am not even talking about mainframes or Visual Basic desktop applications. I’m talking about last generation .NET and J2EE platforms which are too heavyweight, slow and bulky to change. Change, iteration and experimentation is what’s important in the new world and these platforms are just not optimised for that.

Many enterprises who I speak with through Contino are seriously feeling this pain now, even though they don’t consider their technology legacy or outdated.

Why Now?

Of course, people have wanted better, faster, cheaper since the dawn of time. Disruption is a mature concept and legacy technology has also been an issue for enterprises for a long while.

What is different this time is that there is now a burning platform. Every business is competing on the strength of their technology, and nimble startups can come along with lower barriers to entry and eat their lunch. Likewise, more established players who are much better at software delivery can branch out into new markets and beat incumbents on their own turf. For instance, what would happen if Amazon launched a bank? Their technology capability would allow them to leapfrog established players in a very short space of time. Established businesses are seriously exposed.

Decoupling, modernising and re-platforming legacy code takes a long while. Some of these projects are going to need significant amounts of work and significant budgets to re-platform, but the cost of not doing is huge if the organisation doesn’t survive in the new software centric world. I suggest starting those conversations now in order to swerve what future generations could deem as the great legacy code crisis of 2016!

May 7, 2015
4 Ways the Cloud Has Influenced Applications Troubleshooting
The rise of cloud computing has ushered in an era of unprecedented productivity for developers over the past several years. For those who have embraced this new world order, gone are the days of long lead times for hardware procurement and installation, architecture defined by slow-moving hardware upgrades, hardware-constrained scalability and flexibility, and a world where only sys admins have access to the infrastructure. But, as the barriers between development and delivery disappear, new challenges have emerged that can disrupt the lives of developers and slow down delivery of new products and features, giving back some of the efficiency gains that the Software-Defined Data Center (SDDC) created.

Whether you’re new to the cloud, or you’ve been around since before cloud was cool, you are likely to see four common challenges emerge that can make troubleshooting your applications in the cloud more difficult. Let’s take a closer look at these common pain points first to help build awareness around the challenges, and then I will offer some suggestions for how to prevent these hurdles from tripping you and your team up when it comes time to unravel an application troubleshooting mystery.

Shifting Ownership

If you’re adopting the cloud with limited support from an operations team, or perhaps you’re one of the growing numbers of DevOps or even no-ops teams who find themselves bridging both the operations and development worlds, you will find that the responsibility of operating and supporting both your app and your infrastructure, at some level at least, will introduce a new dynamic that you may not have contemplated.

True, the ability to roll your own architecture without the burden of dealing with physical devices is liberating and far more efficient. But, as developer tools, deployment tools, and cloud operations tools become inextricably linked to one another, the old boundaries between who is dev and who is ops become blurred or even get removed altogether. This means the dev team is suddenly an integral part of operations, whether by design or by default, adding yet another responsibility for developers whose chief mandate is often to go faster. The more time you spend in the operations realm, especially in troubleshooting your app or the cloud resources it depends on, the less time you are able to devote to adding new value through code.

Lack of Transparency and Burden of Proof

While it’s true that having the full benefits of the cloud available at the press of a button is awesome, you wouldn’t be faulted for having a bit of nostalgia about the “good old days” of being able to have a conversation with a real live person down the hall about real physical hardware that’s either healthy or isn’t (along with the ability to actually lay hands on it). An old familiar refrain when something went wrong with an app in production was for the burden of proof to rest initially with the ops team – prove the hardware is working, the network is healthy, and the SAN hasn’t lost disks before making the dev team dig in. Honestly, everyone was just hoping against hope that it was something “easy” in the infrastructure, because when it was the app, that’s when things got hard. Well, that script has been reversed with the cloud: now the burden of proof is on the dev team, because what’s really hard is finding a problem that originates with someone else’s complex, abstracted, virtualized data center.

App returning a 500 error or performing poorly? If you’re using something delivered as-a-Service, such as database, queues, cache and the like, you won’t really have any visibility into health other than the cloud provider’s status page and whatever you can directly observe. It’s either working correctly and is speedy, or it isn’t; if it isn’t, life gets a lot murkier. Likewise, servers can be monitored, but you can’t really tell why your virtual resource’s performance has trailed off if you are the victim of something environmental that’s out of your control.

And, no matter how good the support team is at your favorite cloud provider, it’s rare that they will be as responsive to your requests for more information on an issue as your own in-house ops team could be, and they won’t be as well-versed on your architecture. To varying degrees, you’re at the mercy of the cloud provider for consistent, reliable services, and it’s also up to them to offer timely insight when issues arise with the services you depend on. Your mileage may vary, of course, as to whether your cloud provider offers this level of communication and transparency. But, if they don’t, then the burden of proof rests squarely with you to show that the issue isn’t in your app. Quite a reversal of fortunes, isn’t it?

Easy Complexity

Compounding the challenge of sorting through infrastructure issues vs. code issues is the simple fact that applications are becoming far more complex, and in many cases, portions of the overall architecture may be transient in nature. Combine complexity with impermanence and you have a recipe for some real Sherlock Holmes-caliber mysteries at times.

The incredible thing about an SDDC is that you can create nearly any kind of architecture required to support your application stack’s needs, all relatively easily – if you can dream it, you can build it. Want to cobble together .NET, Java, PHP, Node.js, Ruby, Database-as-a-Service for SQL and NoSQL, Message-Queues-as-a-Service, and Search-as-a-Service? From a cloud deployment perspective, it’s been made devilishly easy to deploy and get started. But, with that ultra-polyglot approach and a heavy reliance on software-defined services comes a new set of challenges:
- First, you have a variety of services that are black boxes to you. Each of these services comes with its own set of tricks for gaining insight into performance and availability, but each one may be different in how you monitor and troubleshoot.
- Learning how to support a variety of different technologies creates drag on your delivery velocity. It’s hard enough learning the performance and reliability tricks for a few technologies; trying it for a wide variety can draw focus from the real goals of building new value through software and making the business more successful.
- Not every monitoring tool can support every technology stack, and the wider you cast the technology net, the harder it can become to support your full stack from a single monitoring tool.
- If you’re using dynamic (transient) resources, such as scale-on-demand servers, you are quite likely to lose critical data that you need when troubleshooting a problem if you haven’t given thought to how you preserve critical insights that disappear with the server when it’s de-provisioned.
More Frequent Change

And, finally, we come to the double-edged sword that brought this all about in the first place: going faster! The increased agility that the cloud brings, especially when coupled with dev tools that are integrated into the delivery cycle (think PaaS environments), has a way of shortening delivery cycle times and increasing the number of releases crammed into a given week, month, and year. This is especially true in organizations who have also adopted agile development practices. Code can flow to production smoothly with greater frequency, and architecture changes can be made far more swiftly and easily. Unfortunately, with more frequent code releases and architecture changes comes more frequent opportunities to break something.

A big part of the movement toward Agile and Lean is also the notion of always moving forward – rather than rolling back a release in the event of an issue, detect problems early and patch them quickly. To enable this mandate, however, requires two things that are often missing if you are coming from a slower moving environment or from a more traditional hosting model: 1) developer visibility into a baseline of behavior telemetry to know what “good” looks like historically; and, 2) instant feedback on the health of the application post-release relative to that healthy baseline. Without this, it’s hard to know if you’ve made gains or losses with your release – your users are often your only real barometer.

So… How Do I Code More and Support Less?

There’s no denying that the cloud has impacted the life of many developers, mostly in a very positive way. Of course, with new technologies and capabilities always comes a new set of challenges to overcome. In the case of cloud-hosted applications, this includes challenges to effectively and efficiently supporting those applications in their new environments so that the gains in productivity aren’t given back in support of the application.

So, what can development teams to do adapt to and overcome these challenges?

There are 3 basic steps that every development team should take to make supporting cloud-based applications easier.
1. Establish Access, Process, and Protocol – The first order of business for helping developers support their cloud-based apps more effectively is giving them safe access to the information and resources they need. Unfortunately, all too often in cloud environments this is an all-or-nothing proposition – full login rights to servers and even potentially full rights to the management portal, or no access at all. Make sure to establish the correct access methods to your developers so that they have the visibility and access they need, without handing over so much control that it increases the likelihood of accidents.
2. Design Supportability Into the Application – Once your application is in production, there are several common questions that you will needto be able to answer at a moment’s notice about your application: Is it (and everything it depends on) running? Are users satisfied with the performance? Is anything silently failing and frustrating users without setting off alarms? If something failed, whowas impacted, and what caused the issue?There are also some things that simply cannot be measured and monitored from outside of the application, but which speak directly to the health and well-being of your application. To enable you to quickly answer the inevitable questions, consider incorporating the following:
  - If it moves, measure it. Report application metrics and KPIs from within your code in order to see events and data that would otherwise be locked away from you. Some events and metrics only you, the developer, have the power to expose. Knowing how your app behaves at a core level can provide levels of insight that prove invaluable when searching for troubleshooting clues. If you can configure monitoring and alerts for those metrics, even better. We’ve elaborate on this subject in this article Errors & Logs: putting the data to work
  - Log often, and log meaningfully. If you only report errors, you will lack the critical insights necessary to help point to the root cause of the error. By logging at, say, info or debug instead of just warn or error, you will have the breadcrumb trail you need to find it. It’s impossible to get the state of the system after the fact – you need to have logged it at the time of the event.
  - Centralize your insights. Remembering that life in the cloud can be both quite distributed, and quite transient, it’s always good to bring everything – logs, errors, custom metrics, and other telemetry – into a central location for normalization, correlation, and continuity. You may need the data, and what it tells you, well beyond the ephemeral life span of your cloud resource.
3. Identify Health Baselines Early – Key information like message queue length, average request time, app pool resource utilization, custom metrics values, log and error rates, and more can all be charted for your application these days – monitoring and charting isn’t just the domain of ops tools any longer. Understand what your app looks like both when healthy and unhealthy, preferably starting with pre-production environments even, so that you can see how your application morphs from release to release as well as with different loads and as your architecture evolves. By baselining as far back as dev and QA, you can often catch problems well before they impact customers and send you and your team scrambling.
Conclusion

There’s no denying the cloud brings incredible capabilities to the lives of developers: speed, agility, flexibility, scalability, and more. As with any new, disruptive technology, new challenges are also par for the course. By applying some basic strategies for application management, monitoring and troubleshooting, you can have all of the advantages of the cloud without giving back the gains during those critical support engagements, and have happier team members and end users as well. At Stackify we believe we offer a solution to the issues presented in this article start your free trial today stackify.com/sign-up

About the Author/Craig Ferril

Craig Ferril, COO at Stackify. Craig leads the operational aspects of Stackify, making sure that the business is as nimble as the development team. He brings with him a passion for applying Lean principles to software and business alike, along with 15 years of experience leading software engineering and IT operations for start-ups, SaaS companies, and large enterprises. His background included leading teams that supported production software, which is where his passion for Stackify’s mission of helping developers and DevOps teams originates from. A Renaissance man wannabe, Craig dabbles in everything from brewing beer, to photography, to driving on a race track at high speeds. Follow him on Twitter @cferril
May 6, 2015
Webinar: From DevOps to Dev-Test-Ops – Automate Your End-To-End Software Pipeline
Software quality matters. Adopting DevOps practices and increasing collaboration between Dev and Ops helps align teams around what matters to the business: Shipping product. Thorough testing is a critical step that is often handled manually, introducing risk and unpredictability into the process. Join Electric Cloud and Tricentis as we demonstrate proven techniques to ensure your software quality by automating more of your end-to-end software development lifecycle, including testing.
Join this webinar to learn:
- How DevOps practices help your Dev, QA and Ops Teams work more efficiently
- How test automation eliminates manual handoffs and increases coverage
- How detecting errors quickly can help developers optimize quality
Event Recorded Thursday, May 28th, 2015

Video

https://www.youtube.com/watch?v=1l-m2w9G-DU

Slides

[seoslides embed_id=”0864238fd063″ script_src=”https://devopsy.kinsta.cloud/embed-script/7112/7155/” overview_src=”https://devopsy.kinsta.cloud/slides/7112/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”From DevOps to Dev-Test-Ops” /]

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Dr. Gerd Weishaar Vice President of Product Management, Tricentis

Dr. Gerd Weishaar has over 20 years of experience in product development and product management from various software companies, including Segue Software, Rational Software and IBM. As VP of Product Management at Tricentis, Dr. Weishaar currently manages a team of experts who have a strong focus on market demands and needs. His team is responsible for managing the entire product life-cycle of the Tricentis Tosca Testsuite and product marketing related content and communication. Dr. Gerd Weishaar is a computer science graduate of the Johannes Kepler University in Linz, where he also obtained his Ph.D. He is also an MBA graduate of the prestigious MIT Sloan School of Management in Cambridge, Massachusetts, USA.

Anand Ahire Director Product Management at Electric Cloud

Anand has over 13 years of experience in product management, marketing and development and is a Pragmatic marketing certified product leader and customer advocate. Prior to Electric Cloud, he lead product marketing teams at BMC Software and eGain Communications and is very experienced in agile development methodology, DevOps, Continuous Delivery, IT Service Management (ITIL V3 Certified), application monitoring and automation. He holds an MBA in Information Systems and Marketing from Asia’s most premium business school Indian Institute of Management, Ahmedabad and a Bachelor of Engineering Electronics and Telecom from the College of Engineering Pune.
May 4, 2015