devopsy.kinsta.cloud

Category: Features

Digital Disrupters – Building a DevOps Leadership Profile
While the advancement of DevOps methodology remains fairly nascent for many organizations, an ever-expanding class of leading practitioners are evolving a wide range of related best practices.

Beyond the well-worn concept of “unicorns” – the scant few organizations that stand as mythical examples of DevOps nirvana – this broader set of early adopters have begun to pull back the curtain on their efforts, lending further detail to the strategies that have bred this current model for success.

Last week, industry analysts Freeform Dynamics published valuable research that highlights the ongoing work of such DevOps innovators, dubbed as “Digital Disrupters” for their accomplishments in pursuing larger digital transformation. The report “Exploiting the Software Advantage” – sponsored by CA Technologies, outlines a critical set of initiatives crucial to navigating the DevOps landscape.

What are the specific hallmarks of those organizations leading the charge? Where are others struggling to catch-up? Many of the Freeform Dynamics survey results, based on 1442 respondents, reaffirm widespread DevOps observations, while other findings serve to shed new light, including:
- Everyone builds software: Perception is, in fact, reality and to deeply engrain digital transformation, Digital Disruptors are increasingly identifying with this mantra. While 95% of leaders have committed to becoming more app-centric, only 51% of mainstream organizations have adopted this persona. Similarly, 84% of Disruptors directly identify as “software companies”, regardless of industry, compared to 40% among the masses.
- Transformation is required: This point may seem obvious, but it certainly bears repeating. A whopping 92% of leaders have actively moved to break down traditional silos between Dev and Ops, with 51% of those organizations having already completed this work. By comparison, only 18% of mainstream organizations claim to have done the same, supported by 59% who at least share this more collaborative DevOps vision.
- Commitment is critical: This may also seem like a no-brainer, but the numbers bear out this requirement. Some 77% of Disruptors have agile development methodologies in place, with 70% having “broadly” implemented DevOps activities. For mainstream organizations, these metrics rate at only 31% and 21%, respectively; leaders are going all-in and appreciating the benefits, and those that follow will need to do the same.
- Experimentation is omnipresent: To garner the benefits of continuous delivery, embracing trial and error is a must. Among Disruptors, 93% recognized the need to “experiment and fail quickly on the road to success”, compared to only 58% of mainstream organizations. Some 95% of leaders have already shifted from fixed product cycles to continuous innovation, while only 56% of the mainstream have made this leap.
- APIs are everywhere: Ubiquitous integration, both in-house and in connecting to third parties, has only increased emphasis on the API. Disruptors are resoundingly focused on API management, with 68% using APIs to integrate third party services into their applications, and 66% to offer external access to systems and data. Mainstream peers compare at only 26% and 24%, respectively, denoting a sizable API management gap.
These are only a handful of the most dramatic and obvious areas where DevOps advocates have clearly re-architected their approach, separating themselves from those organizations that have yet to go all-in; it doesn’t stop there.

As highlighted in the research, other areas of differentiation and dichotomy include cross-functional alignment, emphasis on digital channels, use of digital to drive core business efficiency, and even funding of digital investments.

Beyond these key philosophical milestones that litter the pathway to DevOps success, the survey also highlights the vast array of strategic goals that these organizations have sought to accomplish. The results spotlight the massive range of significant business benefits that practitioners believe DevOps can deliver.

Leading use cases include:
- Improved customer satisfaction (49%)
- Better workforce productivity (44%)
- Improved customer experience (41%)
- Improved competitive differentiation (38%)
- Better agility / speed-to-market (37%)
- Opening up of new markets (35%)
- Creation of new business models (30%)
- Creation of new routes to market (26%)
If one were to take those outcomes out of context, unrelated to the impact of DevOps, it’s fair to say that they read like a generic list of leading business initiatives – further underlining the movement’s overall relevance.

That’s not to say this is all accomplished easily. Report respondents detail hard won victories that required significant time and investment to achieve all this DevOps-driven advancement. After all, the notion of “disruption” doesn’t exactly evoke images of ease or comfort.

Click here to read the report for yourself – there’s a lot more to be considered. Namely, how well your organization measures up in affecting digital transformation in its own right, and where it can take steps to move forward.
October 14, 2015
DevOps for Systems of Record – A new hope (Preview of DOES talk)
I am speaking at the DevOps Enterprise Summit later in the month and thought I give people a teaser of what I am going to talk about, so that they know what to expect. I am looking forward to share my story – a story of adversity but also of hope – with many of you. (See me on Wed, 21st October at 11:15 at the Bayview B)

So we have all heard about the DevOps and Continuous Delivery stories from our favorite Web companies (Google, NetFlix,…). It is much harder to come across successful case studies with Enterprise-grade Systems of Record. While I cannot provide the 50 times a day deployments for SAP (yet ;-)), I wanted to share my story so far and what I have learned in the journey (both in regards to solved and unsolved issues).

Hopefully this contribution to the discussion helps some of those out there who are looking for a first step. But why should we even deal with COTS and other systems of record? Ultimately for me this comes back to the two gear analogy that I keep using (Two Gear Blog Post) . If you can just ditch your “legacy” applications completely, then congratulations you don’t have to deal with this and can probably stop reading this blog post. For all of you out there that cannot do that, you will be confronted with the reality that even though your digital and custom applications can deliver at amazing speed you are still somehow constraint by your “legacy” applications. Hence speeding up those will help you achieve the ultimate terminal velocity of your delivery organisation. So how do I approach Systems of Record and the DevOps adoption of it?

3 Key steps:
1. Look under the hood to find the ingredients
2. Recreate the IKEA manual
3. Understand the path to production/operations
Step 1. Let’s open the Hood

Ultimately the two things that I am always looking for are the moving parts of the application and the processes to build and deploy the application. Sounds easy, right? Well it often isn’t as easy as you think, especially COTS application try to abstract those processes away. Look at SAP where you make configuration changes in one environment that then somehow get transported to other environments, but you have little visibility into the underlying process (Ok – my SAP experience is 10 years old, so it might have changed, but you get the gist).

Why do we look for moving parts? Well we want to use the common software engineering practices as much as we can and don’t necessarily want to trust the inbuild features for version control for example. So we look for ways to find the source code files or ways to extract the relevant information in text format (well SQL, XML, etc count as text in my world view), this is sometimes relatively easy (Siebel .sif files are just a type of XML for example) and sometimes it is pretty difficult or impossible. These underlying files is what we will store in source control to make sure we understand at each point in time the configuration of the application.

Once you have found the source code, you will have 3 things to do with it:
a) Get it out of the proprietary solution
b) Integrate it with your IDE
c) Solve for Merges
(I will explore this further in another blog post later)

Step 2. Recreate the IKEA Manual
Once you have all the moving parts, you need to understand how it all fits together. Custom applications usually require explicit instructions which makes it much easier to define and automate the instruction set. For systems of record packaging and deployment is often done through UIs and there is usually more than one way of doing it. Experienced operators have found their own short cuts and the reliability of the system depends on having the right guy in the operating centre (I have some stories to tell about not having the right guy on go-live weekend).

Your goal needs to be an “Ikea Manual” that creates the system from the moving parts we identified earlier without requiring complex interactions or decisions from human operators. Ideally all instructions work from the commandline or some programming API, but when all else fails a UI driver like Selenium can solve the really tricky parts of creating and automating the manual user entries in the application. Every black-box step should be drilled open so that you understand what is happening within the system and so that you understand the variations that could cause you trouble down the path.

Step 3. Understand the Path to Production
Speaking of paths…Of course for systems of record the same rules apply as for any other system. You should practice the exact things that you will do to establish the system in production in all previous environments and minimise the difference between configurations. The challenge for systems of records is often the cost associated with production like environments So you might have to look for creative ways to minimise the difference and to parameterise configurations so that you can at least automate for the differences.

So all is good in Mirco’s land of the Systems of Record?
Unfortunately not, there are still many challenges that I am working on. The progress we have made so far allowed for a step change in velocity and reliability, but there are still areas that I want to find better solutions for:
- Unit test automation
- Unsupported activities or no API
- Performance
- Configuration Management skills – the curse of the configurators
- Common Objects
- Operations – the last mile…
I will speak at much more detail about my experiences at the DevOps Enterprise Summit, if you are attending, come say Hi. I am always happy to show you the scars of working with Systems of Record and share war stories.

And for two “legacy” technology stacks that I have done extensive work for (Siebel and Mainframe ) I promise to write more in-depth blog posts in the future.
October 13, 2015
Building a Winning Software “A-Team” with DevOps

The 1980’s TV show The A-team was brilliant. Four ex-commandos with special skills who help the oppressed. Throw in some over-the-top violence where no-one gets hurt, together with some tech wizardry where the team magically create weapons out of old spare parts. Add a catchy theme tune – and voila – classic viewing.

In many ways agile software development teams want the autonomy portrayed by the A-team. And why not? Let’s bring together small teams of bad-ass code junkies. Provide them with enough open source software to build, integrate and deploy virtually anything. While we’re at it, give them the power to smash all the evil villains’ conspiring to prevent the rapid release of software for the oppressed business – like out-of-touch operations, process-crazy service management, or security and compliance police.

So on the face of it our A-Team looks like an IT winner. They save the day and no-one gets injured, right? Well not exactly.

When Agile Autonomy meets an Immovable Object

Autonomy is both a blessing and a curse. On the one hand, letting teams self-organize and self-manage without outside interference seems like a productivity no-brainer. However, when team autonomy descends into selfish technology-centric rants over rational program level thinking, all hell can break loose. Suddenly every team has access to a plethora of super open source tools — need a document style database for your new Python coded microservice? No problem, click here to download, quickly brush up by reading some appdeveloper articles, and hey presto you’re off and running. Rinse and repeat for different programming languages, build tools, code versioning, configuration management and your teams are all swimming in a fast river of technical goodness where considerations about resilience, performance and security can be easily lost.

The only problem is that the river flows down to where it eventually meets guess who – all those out-of-touch operations folks, process crazies, and security guards. Not surprisingly, they view this last minute technical deluge with a more cautionary eye. And since they’re compensated and rewarded on preventing problems, security issues and compliance exposures, they’re not going let any software pass freely into production – well, not without a fight anyway.

And herein lies the problem with the autonomous A-Team. The “A” suddenly becomes more associated with adversarial engagement than anything remotely agile. So cue delays and the business being ticked off yet again with IT.

Lessons from the Art World – Rembrandt and Stradivarius

DevOps with its focus on team collaboration aims to channel the healthy tension existing between Dev and Ops into business goodness. This starts by understanding how and where to engage all that natural team angst.

There’s a classic old sketch from the late British comedian, Tommy Cooper — who walks on stage with a painting and violin, proclaiming – “I bought a Rembrandt and a Stradivarius – the only problem is Rembrandt made lousy violins and Stradivarius couldn’t paint”. He then smashes the violin into the painting – hilarious.

In development we have our own Stradivarius’ who write great code, but have little appreciation on what makes a “complete” system. They can add all functional bells and whistles, but when it comes to compliance, resilience and supportability, forget it – they’re like the maestro violin maker with a paintbrush – pretty crap. Worse still, the only time they get to learn is when they’re forced to slug it out during a gated security review or regulatory compliance session – this usually doesn’t end well.

These issues may be resolved when development, operations and other stakeholders engage much earlier in the software development lifecycle. Here as requirements are established and code begins to take shape, stakeholders can work with development; guiding them on what’s needed for the software to become more secure, perform optimally and be a breeze to support. For starters, this has to include IT Operations sharing years of expertise – like how to exploit monitoring tools in pre-production to equip developers with an early warning system on performance issues as they code, or explaining what’s needed to support new distributed architectures at scale.

Engage Early and Broadly for Success at Scale

Beyond operations, there are many other IT and non-IT stakeholders who should be drafted into the A-Team.

When working on a new web to back-end system integration for example, security could advise development on end-to-end transaction tracing and static-code analysis techniques to help detect code or SQL vulnerabilities. In an API project, threat teams should engage early to model and mitigate against many new attack vectors that hackers can exploit, providing advice on strong, API-specific infrastructure and management. Naturally, if your team is doing anything with mobile payments you better hunker down early with the security and PCI compliance team – or if the agile team has devised some neat sensor, software and cloud technologies to capture and analyze customer-centric data ala the Internet of Things, then early involvement with the legal department on privacy gotchas is a must.

Large scale success from agile teams can be realized when those teams become less feral about their own individual needs and more focused on supporting business objectives at a program level. To this end, and whatever the makeup of individual teams, it’s vital to establish DevOps style collaboration early in the lifecycle; engaging all business and IT stakeholders in order to establish resilience, quality, security and even supportability into the fabric of software as its developed.

Do this and you’ll deliver great software without ever having to compromise speed. Fail, and your agile efforts may just stutter and fail – of course you’ll still have an A-Team, but the “A” now stands for something far less complementary!

October 12, 2015
Dice Breakers: using DevOps principles and nerdery to reimagine Team building
Software is a young industry, and not a very traditional one. Your team can’t always be expected to behave like teams in other fields.

So it’s no surprise that when a development team hears the phrase, “teambuilding exercises” for most of them it conjures up the idea of a room full of awkward people marginally engaged in a trite set of activities.

But given the resonance of ideas like DevOps it is apparent that the benefits of teambuilding are still sorely needed. Software companies can fall into a very ‘silo’ed mentality. This is often to our detriment, and tearing down those barriers is a big part of a DevOps philosophy.

So there is an impasse; prepackaged, standardized teambuilding exercises fall short of a development team’s needs, and the need for the lessons those exercises try to get across is unmet.

Last year, when I was working on Release! the Game, I realized something; the things we do outside of work, still resonate inside of work. That led me to think that Office Game Nights might be an interesting, albeit nerdy, solution to this issue. But before I explain my dice driven solution, let’s talk a little about traditional team building.

Classic Teambuilding

For the sake of discussion let’s say that by and large teambuilding activities all have a similar set of goals:
- Encourage communication
- Create easy references for actual on the job problem solving
- Relieve stress
- Provides a structure for complaints and socializing
How they try to accomplish this varies, but as a general rule they set forward an infrastructure for interaction that is easily explained, and with a mechanic for comparison to the real work day.

For example, in the classic Trust Fall exercise, one person is called out, to fall backwards while their team is called to catch them. Takes a minute to explain, and the concept that we have to rely on and trust our coworkers is applicable almost everywhere.

It’s a fairly simple formula, get the whole office together, present a challenge, collaborate to meet it, and then discuss the vagaries of how you worked together. Your team bonds a bit, and gets some reinforcement on general work principles.

Why doesn’t that work for Software

In the case of software development teams we actually wind up seeing these results:
- Sighs, scoffing, and somewhere in the dozens of eye rolls, depending on team size
- Some variation on the phrase, “I could be getting real work done now.”
- Some variation on the phrase, “At least I’m not doing real work right now.”
- One or two sincerely interested participants
Why?

Whatever your place on a development team your job will revolve around creating or manipulating complex logic chains to overcome some hurdle. This, in and of itself, is not that much different from any other job, the difference is code.

Code is abstracted, it is just the logic. Code doesn’t need a teambuilding exercise it just needs to be formed correctly, tested reliably and it just works. If it has a problem, communication or otherwise, there is a distinct and detectable source of that issue, and one that, most of the time, has a methodical solution.

That’s a simplified explanation, but the key there is that there is an identifiable problem, and an identifiable solution. That just isn’t the case for the social systems that operate outside of the code. Navigating the personalities and relationships that form in a workplace simply doesn’t have the same amount of landmarks that navigating code does.

The pit fall is in thinking that the software you produce, and your company are the same creature, or at least have the same needs.

Teambuilding isn’t about the product. It’s about establishing a better system for the people who work on that software, and helping them make the connections that will make production run smoother.

Teambuilding and DevOps

DevOps principles demand strong communication between the members of your team. The tools, the methodologies, all need the right environment to be applied in.

So if you want to build a team that can really talk to each other, you need to step away from the standardized techniques, and pick up some new tools.

For team building ideologies to function they require a sincere investment on the part of the participants, but, in most cases, they are so pre-packaged that the exercises themselves lack sincerity.

Openly acknowledge the goals that your teambuilding program is trying to achieve and don’t couch it in the window dressing of corporate training. There are plenty of structured activities that get folks talking, let them blow off some steam, and foster a sense of teamwork that can be easily reflected during your regularly scheduled workday.

My Answer?

(spoiler alert: this is where it gets nerdier)

Board games: sweet dice rolling, card shuffling goodness.

Game nights (or days) are a great place to do some socializing, have a necessary structure around that socializing, and encourage creative problem solving either through cooperation, or competition. There are also a lot of them. The landscape of modern tabletop nerdery isn’t just defined by Napoleonic conflict, or real estate monopolies, there really is something for everyone.

Setting up some gaming is pretty simple. Set aside a few hours, pick out a game or two, pick up and pizza or two, and get a few coworkers on board. Don’t worry if everyone doesn’t jump on board, give it a few iterations to build steam.

Here you can take a lesson from a DevOps release strategy, if your first night didn’t achieve your results, try again with some small updates, a new game, different toppings, etc…

Chances are someone in your office already is into games, especially in the software fields. But, if not, don’t worry it’s pretty easy to get nerds on the hook.
October 8, 2015
DevOps- Is [Ops] operations contribution equally Important?
I started my technology writing journey with a 2 part blog (One & Two) on Service Delivery Excellence, before jumping into the DEVOPS bandwagon, but now as I read across all related discussions, I end up feeling that the good kid is always the DEV and OPS are the unnecessary tag along.

We always talk about how the end goal is to make quicker releases, fixated towards adding value with continuous deployments, insinuating that OPS is the roadblock towards that goal, or that collaboration is the name of the game, and OPS should stop being confrontational, etc, etc.

Today, I am on the other side of the fence and will sit on judgment on the question of if any changes are needed at all for the OPS teams to engage themselves into the DEVOPS culture.

The lifecycle framework, defined by ITIL, COBIT or MOF (looking at the ‘Microsoft Operations Framework’ with renewed interest after my initial days of GRC stint) is quite similar across all phases of IT Service Delivery and consistent with the DEVOPS principles of stable, scalable, lean and quicker delivery of value to the user community.

ITSM’s broadly references
- Focus on services rather than systems
- Process oriented management approach
- Continual Improvement as part of their Deliver, Support and Operate lifecycle,
Then, the questions arise:
- Does the Service Delivery Framework (SDF) changes?
- Do we have to revisit the 3P’s (policies, processes & procedures) which are working well, as we move on to align ourselves with DEVOPS?
Historically in almost all large organizations, Operations [OPS] has always worked in silo, minimal trust of the development & testing teams to deliver a high quality change with a very suspicious view of all changes, as understandably they are responsible for the stability and maximizing availability of the Production environment with a consistent user experience.

On the other hand Developers [DEV] are under greater stress to deliver features and fix defects at a much faster pace due to many reasons. Shorter coding windows, cutting corners on testing cycles, deferring performance/ regression issues ( yes it happens!), and of course your team’s efforts are not just measured but the survival depends on the count of production runs rather than on quality, innovation or improvements.

“Throwing a dead cat over the wall” is how someone wrote of the handover of new code to OPS, I wouldn’t agree with that analogy, as OPS will at least expect it to land on three legs, a DOA would be thrown back with the same impunity!

The business value, Operations add in terms of availability and support to the customer far exceeds the risk of adding half-baked features in the ‘need for speed’. On the other hand it’s also imperative that we work towards a goal of a collaborative approach to a stable, sustainable and faster delivery of features to remain competitive.

I define DEVOPS as “combining a right mix of interdependent variables like People, Process and tools for fast and quality software delivery”, and Operations contribution towards this effort spans across all the variables adding immense value towards a successful initiative, with new insight of the challenges and shared concerns in improving the processes and delivering better software.

DEVOPS is not just about creating scalable infrastructure on the fly, or implement newer tools for rapid and automated deployments, or even about creating a SWAT response around monitoring. It is equally about envisaging a collaborative model, ensconced in proven principles and practices in order to add business value by delivering quality software rapidly.

So, what should OPS do differently to be an effective contributor of the DEVOPS team?

To start with, OPS should grab the advantage of being involved at the outset of the planned lifecycle by contributing with constructive inputs and using their expertise in:
- Assessing Infrastructure impact and capacity review.
- Influence design decisions & operational needs.
- Review all Service commitments and SLA’s
- Security and entitlement management
- Highlight any potential changes to operational procedures.
- Update monitoring and alert mechanisms
- Improve automation.
- Upgrade run-books; training of the service desk, share knowledge.
OPS also can keep a strict overview in the issues faced during the deployment/testing journey of the release and measure it against their own operational readiness thresholds.

The best outcome of this collaboration, in my opinion is that there will be no need for a ‘Warranty’ or ‘Initial support’ period by the DEV teams. OPS will be fully aware of the journey and has partnered to ensure the ‘Cat’ has passed the minimum health checkup and also is fully aligned with the changes to the support model from day one.

In fact the ‘Cat’ will no more be chucked over the wall, rather will formally pass through immigration!

Thank you for the time.

Visit my blog http://askhurram.com/

Read On, Live On.
October 7, 2015
Measuring the value of DevOps investments is still to come
Real Value of DevOps

DevOps is a hot trend and certainly on the rise. Companies now have people with the title, and if you search job boards, you see that everyone is hiring in DevOps. ElasticBox and devopsy.kinsta.cloud wanted to understand the tools being used and the perceived value to uncover deeper trends. Specifically, we wanted to understand how real is the value of DevOps for enterprises, and what we learned surprised us.

We polled DevOps specialists, engineers, and IT managers about their level of DevOps adoption and how they measure its real value versus hype. Over 300 DevOps practitioners in both B2B and consumer-facing businesses, answered our survey. Going in, we expected that today’s high-performing IT organizations adopt DevOps like patterns and tools, whether they call it DevOps or not. Our study confirmed this hypothesis. But how much do companies invest in DevOps tools and what is the ROI of these tools? These were some of the answers we uncovered along other insights in the Real Value of DevOps study. You can download the full report here.

What We Learned:

DevOps has evolved beyond hype

Our study reveals that DevOps is a recognized and dedicated function in many organizations, though adoption itself is still relatively in its initial and/or early stages. Many have formed DevOps teams or other cross-functional teams. More than half said they use or dabble in DevOps practices. IT services and software verticals form the biggest group practicing DevOps whether or not they call it that. The data indicates that DevOps adoption has crossed over from cloud-native organizations to the historically traditional companies in finance and insurance.

Cross-functional collaboration is fundamental to DevOps

DevOps is still evolving as a job function. More than half the respondents cited being part of a DevOps team as their primary job function. As part of these cross-functional teams, many perform operations, development,QA and security work. More than half also interact with 10 or more people with a sizeable portion interacting with more than 20 people regularly. As the study shows, both large and small enterprises have a need to collaborate and work across functions. People in development, operations, and DevOps teams increasingly communicate with larger teams. Clearly collaboration is a major driver for DevOps practitioners.

Top three DevOps initiatives: Automated build tests, CI/CD, and configuration management

To learn where high-performance IT organizations invest in DevOps, we asked what initiatives drive their DevOps adoption. A majority identified automated build testing as their leading DevOps focus. Configuration management followed closely. Another sizeable group said they focused on continuous integration and continuous delivery (CI/CD), which usually also includes automated build tests. One way to understand this data is that companies when they reach a certain level of DevOps maturity recognize that cloud application management helps them tie all of these initiatives together.

Expectations on DevOps investments and returns

We explored budgeting across DevOps initiatives to get a sense of where enterprises spend top dollars. Expectations on returns from these DevOps investments showed interesting results. We asked what estimated ROI they had realized over the past 12 months. Our takeaway is that price/value on DevOps tools is not grounded in reality. As the survey data suggests, the propensity to use free, open-source software drives a low spend. And many respondents could not identify the ROI. We believe the tools and projects make us more agile and more efficient, but the return isn’t being captured in a consistent way yet. When calculating the cost of DevOps initiatives, we believe companies often overlook hidden costs such as setup, support, and training.

We believe that over time, enterprises will become more savvy about measuring the return on DevOps investments, both from a people, tools and process perspective. As the function and teams grow, businesses will demand more metrics to evaluate DevOps projects.

Cloud application management, a growing trend

DevOps practitioners have yet to see cloud application management as a category separate from configuration management and cloud provider services. One reason for that is because cloud providers offer in-house management tools. And many practitioners either don’t use such tools or rely on homegrown solutions. Some reported using ElasticBox and others mentioned Scalr, Juju, RightScale, and CliQr.

As companies become more mature in automating their application lifecycle, we see them adopting a cloud application manager or cloud management platform to orchestrate the full end-to-end process. There’s no question that this demand will grow as DevOps teams continue to mature and establish their value in organizations.

More detail and insights are in the Real Value of DevOps Survey report. Download it by filling out the form below and receiving a link.
Real Value of DevOps
First Name*
Last Name*
Email*
Enter Email Confirm Email

Would you like to be added to our newsletter?*
Yes
No
About the Authors/ Carol Carpenter & Alan Shimel

Carol Carpenter serves as the CEO of ElasticBox. It’s her lifelong passion to deliver innovative products that transform businesses. Her roots are in product management and product marketing. She’s proud of how it all began at Apple as a product manager, responsible for the several billion dollar line of Power Macs. Since then, she’s built over 20 years’ leadership experience in large and small technology companies, recently as CMO at ClearSlide, a high-growth SaaS company and as Executive GM for the Small Business and Consumer division of Trend Micro, Inc. When not at work, she serves on the Board of Directors of Dice Holdings (DHX) and co-chairs the non-profit board of Monte Jade. She is a happily certified multitasker, trying to keep up with her two kids, husband, dogs and chickens.

As Editor-in-chief of devopsy.kinsta.cloud, Alan Shimel is attuned to the world of technology. Alan has founded and helped several technology ventures, including StillSecure, where he guided the company in bringing innovative and effective networking and security solutions to the marketplace. Shimel is an often-cited personality in the security and technology community and is a sought-after speaker at industry and government conferences and events. In addition to his writing on devopsy.kinsta.cloud and Network World, his commentary about the state of technology is followed closely by many industry insiders via his blog and podcast, “Ashimmy, After All These Years” (www.ashimmy.com). Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology. His legal background, long experience in the field, and New York street smarts combine to form a unique personality.
October 6, 2015
Developing your organisation’s collective consciousness
Many organizations across the world are taking a long, hard look at DevOps and wondering how they can start to take advantage of its benefits.

The 2014 State of DevOps report has some pretty compelling facts:
- Companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals
- They will have 50 percent higher market capitalization and growth than rival businesses
DevOps might just be the key to organizational survival in the modern business environment.

Sounds good!

So, where do we start?

Organizations that want to start getting the benefits of DevOps need to recognize their implementation for what it is – organizational change. No, not hard-core bureaucratic change management with millions of forms to fill in, but an initiative that needs to win hearts and minds across the organizational.

Remember – DevOps isn’t just an IT thing, and it isn’t just a business thing. It’s about collaboration, communication and integration right across our organizational.

To be successful with any organizational change, there are a few simple things we need. We need a goal, we need a plan, and we need some enthusiasm. If we can’t get our people enthused and bring them with us, our goal and our plan will not have the momentum they need.

One way to build enthusiasm and a common starting point is through education. It’s really important that every stakeholder understands the goal, the plan, and feels they have the tools, skills and level of empowerment to contribute.

Getting staff the training they need can help build their capabilities and create a common understanding across the organization – a collective consciousness. DevOps is a simple concept, but some of the terminology that comes with it won’t be familiar to everyone. When you start to talk about continuous delivery and continuous deployment, you want to be sure that everyone is on the same page!

DevOps implementations can learn from the way organizations have adopted other frameworks in the past. Common mistakes include a statement of management intent with no plan behind it – saying you’re doing DevOps doesn’t mean you are. Making sure your staff are all speaking a common language can really help to deliver success.

The DevOps Foundation course from the DevOps Institute is a great way to start building that collective consciousness and get your staff involved in your DevOps initiative.

The syllabus has been developed by leaders in the DevOps community and looks at where DevOps has come from, and covers topics including:
- DevOps Culture
- Organizational Considerations
- DevOps Practices (the three ways)
- DevOps and IT Service Management Processes
- Automation Practices and Tool Categories
Once your staff are trained, you can start to have a collective conversation about where you can make improvements in your organization, building on a common foundation.

To get the most from your training, make sure staff know why they are attending the classroom course or taking the e-learning, and then have a plan to build on what they’ve learnt when they are finished.

Read more about DevOps courses and find training providers here: http://devopsinstitute.com/doi-reps/

About the Author/Claire Agutter

Claire Agutter is the lead trainer for ITSM Zone, global e-learning providers for IT management professionals. Claire has more than 15 years of IT management experience and loves anything that helps the business and IT work together to create value.
ITSM Zone are the DevOps Institute’s exclusive e-learning partner.
October 2, 2015
Puppet Application Orchestration: Orchestrate the entire stack

In advance of next week’s PuppetConf, Puppet Labs is announcing a major new addition to their lineup, Puppet Application Orchestration. The orchestration functionality will allow users to automate configuration, deployment and management of your entire infrastructure stack, wherever it resides. This is a significant uplift from managing just one instance or server at a time.

I had a chance to speak with Luke Kanies, founder and CEO of Puppet Labs ahead of today’s announcement. Kanies has led Puppet through its 10+ year existence and has seen it grow from an open source project to over 400 employees, raise $87m in venture with over 1000 customers and more than $75m in revenue.

I asked Luke what orchestration meant to him, as I think it is a term that is thrown around a lot in technology but not everyone agrees on exactly what it means. He gave me one of the best definitions I have heard, “orchestration is doing related things in a related way”. In Kanies view the new functionality from Puppet Labs allows organizations of all sizes to “orchestrate their complete software stack allowing for the automation of the software supply chain.”

This orchestration functionality is another step along the way of the eventual goal of a world where software is written primarily by software. This Matrix-like future Kanies believes is inevitable. It may happen in 20 years or maybe 50 years, but it will happen.

The real key to this new orchestration tool is that it is more than just being able to automate multiple servers or instances. It actually orchestrates (there is that word again) how these disparate parts of your infrastructure run. It takes into accounts dependencies and events from other parts of the infrastructure in determining how and when to run other parts of it. Puppet says it best in their press release, “ensures that the right things happen in the right order on the right machines as the application is deployed, updated or destroyed.” This awareness is what makes this really special.

Of course another big part of the equation is that this really does run across your entire stack. Whether it be in a public cloud, private cloud, hybrid cloud, bare metal, on prem or even containers, Puppet’s application orchestration can manage them all from one central app. That is pretty impressive.

To enable this functionality Puppet Lab’s team had to develop some new extensions and additions to its scripting language or DSL. This shouldn’t present much of a hurdle to the thousands of people who already use Puppet Labs products.

Puppet’s new orchestration tool is another indication that the IT industry is becoming more and more app-centric. Applications are driving business and IT with it. Where they live and how they are built is complex and IT teams are looking for tools that make it simpler to deploy and manage these far flung, multi-homed applications that are popping up at ever increasing rates.

Kanies himself will be demonstrating the orchestration module at PuppetConf next week during his keynote on Thursday, October 8, at 9 a.m. PT. If you are not attending PuppetConf you can follow along on the Livestream.

It will be interesting to see how this new Puppet tool changes the market. It could set off another wave of integration and third party functionality that leverages this full stack management. Who knows maybe somewhere right now there is some software writing some software that will take advantage of Puppet Application Orchestration.

October 1, 2015
Cloud Visibility: The Security Achilles Heel

As organizations accelerate their DevOps practices and move toward continuous delivery, cloud adoption plays a pivotal role. But visibility into cloud infrastructure and provider practices will remain a security Achilles heel until businesses can get better monitoring and insight into public cloud assets. According to a new survey out by the SANS Institute, even as the amount of sensitive data housed in public cloud infrastructure explodes, many organizations haven’t found a way to lick the visibility problem.

Sponsored by CloudPassage and conducted among nearly 500 IT professionals, the survey showed that both PaaS and IaaS are on a huge upswing. In the next 12 months organizations report that they will approximately double usage of both models. IaaS in particular shows the biggest growth among cloud usage models, as 29 percent of organizations report they’ll deploy IaaS for the first time in the next year. Among the major drivers for this growth, 61 percent of organizations said time to deployment was key, while 54 percent said they were moving to the cloud because they can’t scale their own solutions.

In those cloud deployments, well over half of organizations are processing or storing sensitive data in their public cloud environments or aren’t sure if they have sensitive data in the cloud. At least one in five organizations said they use the cloud to store or process intellectual property, customer financial information or health records. Meanwhile, 52 percent said they used the cloud to store and process business intelligence data, while 48 percent store or process employee records.

Visibility concerns trump all others when organizations related their problems with cloud adoption—nearly 60 percent reported having issues with a lack of visibility into service provider operations. Nearly half of organizations related they had issues getting proper incident response support from providers due to visibility issues. And 46 percent reported having issues with VM and workload visibility. While not quite as widespread as general visibility woes, a quarter of organizations reported that provider-introduced vulnerabilities resulted in a breach or incident. Unfortunately, organizations are more likely than not unable to test for these kind of issues proactively. Only about 24 percent of organizations work with providers that allow them to do penetration testing on their public cloud assets.

Diving deeper into this issue, one of the big problems is the inability for organizations to fold their cloud operations into overall security monitoring and management—37 percent of organizations reported there’s just a lack of consistent security controls that integrate with on-premises tools and security management.

“The biggest issue, which goes back to the problem of visibility into internal cloud provider operations, is the lack of access to log files and other forensic artifacts, experienced by 53% of respondents,” says the report’s author, Dave Shackleford. He recommends that as organizations evaluate their public cloud relationships, they consider controls like logging, multifactor authentication, encryption and compatibility with security products that work natively within that cloud infrastructure.

September 30, 2015
The business benefits of DevOps

As DevOps has become more of a mainstream concept it seems like there’s less need to define what it is or explain what it does. As prevalent as DevOps is for those of us who work in the world of DevOps or organizations that have already embraced DevOps there are still many businesses out there muddling along the old-fashioned way and wondering why they should care about DevOps.

The simple answer is that not caring about DevOps may be suicidal. The 2014 State of DevOps report found that organizations successfully implementing DevOps tools and practices lead competitors in almost every relevant metric. Two statistics that stand out from that report are that companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals, and had 50 percent higher market capitalization and growth than rival businesses.

Why is that, though? What is it about DevOps that leads an organization to be more profitable and productive? It’s a combination of three things, really: faster delivery times, greater stability / reliability, and freeing up time to focus on value.

Let’s break those down some. DevOps is an evolution of the Agile development methodology. In fact, I’ve asserted in the past that DevOps is really just a matter of taking Agile principles and applying them to the rest of the company outside of software development. Whether Agile or DevOps the result when it comes to developing software is faster, more frequent delivery.

Next we have greater stability and reliability. It might seem that the traditional linear method of developing software and releasing it on a pre-defined schedule is more stable. Developers and the rest of the organization have plenty of time to refine the code before it’s deployed, they know exactly when it will be deployed, and they know it basically won’t change for another year or so when the next major release is scheduled. The reality is the complete opposite in many cases.

Developing with a rigid process methodology like waterfall means that only the changes and features identified at the beginning of the project are included in the release. As the need for improvements or additional features is identified during development those things are sidelined and added to a list to be pursued in the next release cycle. By the time the software is developed, tested, and deployed it is already out of date to some extent and bugs or issues that are identified take longer to address or get pushed to be handled in the next major release.

The whole process is slow and results in less stability and reliability. DevOps yields greater stability and reliability because the faster development and more frequent release schedule enables organizations to identify and resolve issues immediately.

Those two things combined mean that developers and others throughout the organization have more time available to focus on improvements and innovations that contribute to the bottom line. Organizations that have embraced DevOps also generally have tools in place to automate routine tasks which enables individuals to dedicate more time to growing the business and less time to pissing on fires and maintaining the status quo.

DevOps has come a long way in just a few short years. There may still be companies out there trying to figure out why they need DevOps, but those companies won’t be around long. They’ll either figure it out and jump on the DevOps bandwagon or they will no longer exist to worry about it.

September 29, 2015