DevOps and cloud computing are not mutually exclusive, though their relationship has often been uncertain and confusing from a layman’s perspective. While cloud computing relates to technology and services, DevOps is more about processes and process improvement. However, both DevOps and cloud computing are vital in every organization’s journey toward an effective digital transformation.
Cloud-centric DevOps Automation
Cloud computing’s centralized nature enables a standard and centralized platform for DevOps automation. Using a cloud platform resolves issues in centralized software deployment caused by the distributed nature of enterprise systems.
DevOps objectives including continuous integration (CI) and continuous delivery (CD) are supported by most of the private and public cloud service providers. This ensures centralized governance and control, in addition to reducing the costs associated with DevOps automation on-premises. DevOps utilizes orchestration systems that can proactively monitor the cloud data sets and application workloads. End-to-end automation is a prerequisite for deriving the full advantage from the cloud.
By expanding the concept of continuous improvement to cloud-based platforms, DevOps ensures lesser system vulnerabilities and greater security.
DevOps Best Practices for Effective Cloud-Based Computing
DevOps provides several core capabilities that assist organizations in effectively handling cloud challenges. These include:
Infrastructure as Code (IAC): IAC comprises the provisioning of servers and installation of application code, the core components of the system architecture.
Automated Application Deployments:DevOps practices facilitate the creation of a fully automated application deployment pipeline that is of great importance in the development life cycle.
Application Lifecycle Management (ALM): DevOps principles such as continuous integration and delivery help in effective ALM in the cloud.
Continuous Quality Assurance (QA) and Testing: DevOps capabilities address the challenges for QA and testing in the cloud by provisioning multiple test environments using cloud-based resources that result in enhanced quality and productivity.
Knowledge-Sharing with the Cloud Provider: DevOps promotes the concept of knowledge sharing between organizations and SMEs of the cloud service providers throughout the application life cycle using online communities that are focused on fostering communication and collaboration, thereby ensuring that most risks are mitigated effectively.
The Significance of Cloud Computing vis-á-vis DevOps
Cloud computing complements DevOps in several ways. The application-specific infrastructure in the cloud enables developers to own more components easily and enhance their productivity and efficiency. It allows developers to create the development environments quickly without the need for IT operations to provision resources and infrastructure.
Cloud computing ensures flexible IT infrastructure in addition to enabling greater business agility. It propels IT transformation by helping organizations in streamlining and embedding DevOps processes.
DevOps tools and services eliminate human error and help in establishing repeatability by automating and streamlining the process of building and managing code.
IT Transformation Enabled by DevOps with Cloud Technology
Cloud computing coupled with DevOps ensures that scalability becomes an integral part of application development, thereby contributing to reduced infrastructure costs and increased global reach.
Cloud-based operations increase the availability and failover ability of applications in addition to eliminating downtime, which leads to improved business reliability and rise in customer satisfaction.
DevOps automation and IAC help in reducing the complexity of the cloud and improving system maintenance. Additionally, the automated repeatable processes increase security controls. Process streamlining and faster access to the development environments ensure improved product time to market.
In Conclusion
By realizing the importance and prioritizing the usage of DevOps in the cloud, organizations can derive a huge number of potential benefits including enhanced agility and reduced operational costs.
It’s been nearly seven years since Marc Andreessen’s essay, “Why Software is Eating the World,” brought to light software’s role in determining the next wave of winners and losers.
Today, his essay is still relevant. The past decade saw the consumerization of IT in business. It also witnessed the shift in software consumption from desktops to the web and to mobile apps today, reflecting a mobile revolution. Software continues to eat the world, having moved to a “mobile only” development model.
This revolution is defined by disruptive companies including Airbnb, Uber and others that run with more leanness and agility compared to their 20th century counterparts. These companies have few physical assets, relying instead on software.
Since Andreessen’s essay, the software development life cycle has expanded and evolved—from waterfall to agile processes, from testing against just a handful to thousands of mobile devices and from serving a regional to a global one user base, to name a few examples. Demands for speed and quality control have been key drivers, and as a result, the life cycle moves faster than ever. A record number of developers are writing a record number of programs. This expands each and every day as businesses small and large, in markets old and new join, the mad dash to create more software, better, faster and cheaper.
Creating Software, Fixing Mistakes
Indeed, the software development curve is evolving at breakneck pace. But while the cost of creation decreases, the cost to correct a mistake increases. How can developers and their organizations stay ahead of the curve? Here are three principles we’ve observed from studying more than 25,000 customers in the last seven years:
Implement Modern Development Techniques Such As CI/CD
Continuous integration (CI) and continuous delivery (CD) are two modern development practices designed to help teams release quality code faster and continuously. CI/CD has gained popularity over the past few years, and for good reason. When implemented effectively, CI/CD shortens delivery times, improves overall quality and enables teams to adapt quickly.
Key to a successful CI/CD practice and ensuring quality software development is the practice of testing throughout the development process. The cost of fixing already deployed broken software is high, and it’s crucial to ensure your software works properly on all platforms and devices to minimize customer abandonment. This is especially true when you consider that the cost of regaining a customer is four times higher than winning them in the first place. Getting software right the first time through a culture of continuous testing is critical to success.
What does ideal testing look like? It is automated, runs fast and includes good coverage. As the already broad ecosystem of operating systems, devices and platforms expands, this last point is critical. What good is your app if it doesn’t run (and, by extension, monetize) properly when it gains popularity in some part of the world with users on a different platform from the one you tested on? Developers need to ensure their software works on as many different combinations of browsers, devices and operating systems as possible, to help their business reach the maximum number of users.
Introduce ‘Self-Driving Software’ Practices, Technology into Your Development Cycle
When everyone is running so fast, it’s critical to ensure the software you’re writing actually works, won’t break your infrastructure and will actually be used by consumers. The “garbage in, garbage out” model is not an option, especially given the expense of creating software today. While the barriers to create software have lowered over time, the bar has risen in terms of creating something really remarkable.
The good news is that we are at the cusp of attaining the holy grail of software development. I have interviewed multiple engineering and quality leaders at many of our customers who are pushing the limits on ultra-efficient DevOps. Through a streamlined process (which, frankly, is nothing short of beautiful), they are able to create a single, seamless flow between development to testing to operations to deployment and monitoring—without compromising on speed or quality. The key is to prioritize speed over cost and quality and agility over all else. If an organization isn’t following this principle, they risk being left behind. In the “Stack Overflow developer survey 2017,” more than 65 percent of developers indicated that they follow some kind of agile development methodology at work.
The end result is deploying software almost immediately as soon as it’s written, for release as quickly as possible. Companies strive to achieve this scenario, and the highest performing organizations have already reached this development dream in some manner or another. Attaining CI/CD and automating all the tasks involved in creating a test system in real time is one of the arenas in which the next big software battle will be fought. The quest for the holy grail of software development is on.
Support (and Attract) Your Engineering Talent by Providing Flexibility
In the mad dash to develop amazing software, engineering has become among the hardest roles for companies to recruit for.
Organizations need to be nimble enough to attract top engineering talent. Part of being attractive to potential hires is understanding that software can no longer be monolithic. More than ever, the talent pool expects choice in the languages, platforms and tools they can use to develop and work most efficiently. In the Stack Overflow developer survey, participants valued the languages, frameworks and other technologies they’d be working with as a critical (4/5) decision factor while assessing potential jobs. This doesn’t mean providing a “free for all” for developers to use everything and anything they want—rather, it’s all about adopting flexibility. The companies that are most attractive to the best engineers follow this principle.
Conclusion
Today, we’ve moved from software eating the world to the world eating software. Developers simply have no control or knowledge over where their website or app is going to be downloaded or accessed from. Unless it’s an internal app behind a firewall, any software developed today by definition is consumed by the global community.
Even if you test for all scenarios and devices, the future will always bring new devices, browser versions and operating systems. Your customers may use these instead of what you initially tested for. One option is to test for emerging devices in an in-house lab; however, that means committing to resources, time and qualified engineers to maintain it. In most cases, this approach is simply unsustainable.
Companies must focus on ensuring their software works both with what’s out there today and with whatever browsers, devices and platforms will be out tomorrow. This is a major challenge, requiring considerable investment. Companies need to decide whether they are in the business of testing software themselves, or leverage solutions that are.
Well before Andreessen’s seminal article, Geoffrey Moore wrote “Dealing with Darwin.” Here he he expounded upon the concept of core vs. context. Organizations will be well-served in deciding (quickly) whether building an in-house testing infrastructure is core or context to their business. The alternative is falling behind—or worse, being eaten up by the competition.
It has become somewhat of a standard practice to tell people, “DevOps is a journey, not a destination,” which attempts to convey the fact that there is no end point that is set in stone. But a journey is a well-planned, point-to-point trip, while DevOps transformation is a messy, figure-out-the-next-steps-as-you-go trip.
So I propose we quit calling it a journey and start calling it an odyssey. This summer, when my mother takes her 10,000th trip back to Germany, it will be a journey. She’ll start in Cincinnati, Ohio, and travel through a couple of states before finally making her way to Hamburg, Germany. That’s a journey. She knows where she is going, and the discrete steps along the way.
Her original flight from Germany? That was an odyssey. The trip went Berlin->Naples->Shanghai->Hawaii->California->New Jersey. Of all of that trip, only Berlin->Naples was a choice. Or, rather, the decision to go to Shanghai was a choice that required Berlin to Naples—very much in line with your DevOps choices making decisions for you along the way. And just like her family, you have no idea what your choices will be in a few iterations. They knew they had to go to Shanghai because that was the only port that would allow them in without visas, and they couldn’t get visas. After that? They knew they wanted to get to the United States or Australia (one assumes anywhere far from the insanity that was engulfing Europe and Asia during World War II), but how to get there was a total unknown. “First we start, later we finish,” was her father’s description of the goal.
And that’s pretty much what DevOps is: First you start, and in the fullness of time you will discover things you hadn’t even considered when starting that just make sense and improve your overall position. There will be fits and starts, wrong turns and massive improvements. It is an odyssey, and one that is designed—just like my mothers’ family’s flight—to make things better in the long run.
For example, the choice of Ansible or Puppet will make other choices easier. Giving teams more autonomy and increasing communications will make other choices more obvious. It will evolve into more than the first iteration’s goals would suggest, and that’s a good thing if increased agility and reduced manual intervention are the results.
So keep on that odyssey, but don’t expect a simple end. More likely, the identification and acquisition cost of future improvements will cause more than the benefit they introduce, and you’ll find yourself in a better place, ready to breathe a bit and let the market find new ways to improve all things DevOps.
Which is cool, because that should be your final goal: “We have improved so much that any improvements we could make right now would offer minimal incremental improvement for a significant cost.” At that point, your journey isn’t done, but you’re able to sit and take a rest, consolidate gains and assess future possibilities.
And until you hit that point, be excited that every iteration of DevOps is improving responsiveness and taking you closer to your goal.
Shameless plug: Read about my mothers’ odyssey here.
Javascript (JS) is one of the most widely used and beloved programming languages in history. This can be attributed to its fairly light learning curve and impressive functionality. Designed by Brendan Eich in 1995, the language has seen steady gains in use for more than 20 years.
JS itself is a high-level and weakly typed language, which means it is powerful and less prone to errors than other coding languages. It achieved early success and is now integrated on both the client side and server side.
Most applications and OSs come pre-built with JS development capability. It has become ubiquitous in the web development market and continues to be the strongest and most popular web language out there.
With that in mind, here are five resources for JavaScript developers:
Codecademy
Codeacademy is one of the most invaluable resources a programmer can have. It offers tutorials and lessons on hundreds of topics and provides copious amounts of examples to bolster your programming skills. JS has its own page at Codecademy filled with lessons and coding tests to hone your skills and promote better learning.
Codewars
If there is anything that can hone your programming know-how in real-life situations, it’s Codewars. This handy website has weekly challenges to conquer in JS submitted by real people. It puts JS developers in the hot seat and allows them to deal with situations that they may find in real-life work environments.
It also challenges the knowledge of experienced programmers and enhances their practical skills. Troubleshooting assistance is another big help for programmers just starting out, as it helps identify the small mistakes that can prevent compiling code.
MDN
The Mozilla Developer Network (MDN) is a remarkable resource for all JS programmers as it continually updates with the best practices for coding. It has a gargantuan community and is constantly evolving to fit the needs of newer applications.
For developers, MDN provides unique and incredibly detailed documentation on everything from developing for traditional web to mobile web development. The MDN Web Docs has no equal when programming JavaScript, as it guides you from beginner to expert effortlessly, it seems.
Libraries
This is where JavaScript really comes into its own as a powerful platform and highly functional language. JS has a library for everything from GUI to to form applications.
The most popular library is JQuery, which is a DOM (Document Object Model) manipulation framework designed to make all parts of a webpage customizable. JQuery, like the other libraries, seeks to simplify syntax and provide greater readability across the platform. This makes JS an incredibly customizable language that makes coding easier without losing the functionality of the language.
Code-Alongs
One of the most underutilized tools in the programming field, code-alongs make coding much easier than trying to teach yourself from a book or learn from a lecture. During code-alongs, programmers will code live and share their thought processes as they do certain things.
This especially helps new developers who stare at a screen and can’t figure why that goes there. For experienced developers, it can offer an insight to different strategies that they might not know otherwise. Regardless, code-alongs are incredible tools made by individuals for the sole purpose of fostering a love for programming.
Conclusion
Programming jobs today usually require a knowledge of various languages, but almost always JavaScript is a requirement. Its usefulness make it one of the must-learn languages for all coders hoping to make a living. To make life a little easier, and JS a little stronger, there are many resources that can be utilized.
JavaScript is an incredible programming language entirely deserving of its recognition. It is also a necessary tool for programmers of all styles and philosophies. To that end, resources abound for JS and should be used to their fullest. The true usefulness of JavaScript is its amazing community and incredibly involved developers that make JS the programmers dream. If there is any language you should learn now, it’s JavaScript.
A manager, an evangelist and a godfather all walk into a bar.
Okay, this isn’t a bad joke, this is an article about how managers can implement DevOps in large organizations, especially where culture and organizational change hamper efforts. But, I promise, we will talk about managers, evangelists and godfathers.
Uldis Karlovs-Karlovskis (@UldisKK) works at Accenture Latvia. Accenture is a global consulting giant, employing 400,000 with teams and clients across the globe. Uldis helped bring DevOps into the organization and shared his journey—the good and the bad—at theAllDayDevOps conference in his talk titled, “Lessons in Leading a Fortune 100 Team to a DevOps Philosophy.”
Uldis joined Accenture in 2012 and faced three top challenges:
How to maintain quality at such growth?
How to enable continuous learning?
How to stay fast and flexible at their size?
His team was small, they held daily stand-ups that were productive, and they were flexible. Life seemed good, and then his team grew into a “spider.” They still held daily stand-ups, but they were useless because it was just people reporting and no one understood what is going on.
What did Uldis do? Well, he didn’t freak out, if that is what you are wondering. Actually, he did. One morning he, “woke up, realized I had 25 people under me, freaked out and skipped the job for the day.” He walked around, thinking about it and wondering what to do. He thought about his three to four types of DevOps projects and all of the non-project activities that were monopolizing his time. He realized he focused on the urgent over the important tasks, working 10 to 12 hours per day.
What is a manager to do? Have people help him, of course. Uldis decided to create an unofficial role that sounds interesting: the subject matter expert (SME). They would work on non-project activities, increase team engagement, improve satisfaction and assess DevOps maturity in projects. Initially, people were motivated to be SMEs, but they were always busy with other things. So the effort failed.
Uldis had a new idea: Instead of him leading the SME team, he let them decide who wanted to do what, which SME team they wanted to join and who would be the lead SME for each team, and let them set their own goals and how they wanted to work, etc. This helped, but still didn’t solve the problems. Uldis was still burdened with the tyranny of the urgent.
Back to the drawing board, and a new idea was born: evangelists. Uldis broke down 50 SMEs into seven subgroups and added a little hierarchy because the flat structure wasn’t working. Each evangelist led a guild—one of seven. Team members were to talk to their evangelist before coming to Uldis with questions.
But, alas, Uldis was still just handling escalations and talks.
So, what do you do to bring order? Bring in Godfathers.
Now, team members could always go to the Godfather for help. Uldis decided that, generally, each person would have four topics they may want to talk about. For each topic, they have a person to talk to:
SME addresses how to contribute to the company in general
Godfather addresses escalations, such as not happy with the team lead
Evangelist addresses questions about the person’s skills
Team Lead addresses project tasks
Uldis now realized the benefit of this approach: In a way, now, everyone is focused at some level on sales. As we all know, this is important yet very difficult in any organization—but especially when everyone is an engineer.
While his approach has helped him and his team, he also acknowledged, “If I did the same thing today, I would fail, but maybe for different issues.”
Todat, Ulids is looking at improving his culture. As we talk about at AllDayDevOps time and time again, good culture is key to successful DevOps. Uldis, looking at Accenture, noted it doesn’t fit into a typical organizational structure. Reading literature, industry buzz, etc., he realized something was missing from these models, but he wasn’t sure what. He knew they needed to be better.
He discusses three dominant types or organizational cultures:
Pathological – Eight hours of work and your job is done
Bureaucratic – Two to 12 hours of work if the process requires it
Generative – Two to 12 hours of work and I’ll deliver it
Uldis is trying to be at the third approach, and the key to achieving it is knowing that if you are having a bad day, you should leave your work for tomorrow when you will be more productive. Tomorrow it may take more than eight hours, but you will put your best into your work.
His journey is ongoing, but he finished his talk covering a few things they do on his team:
Onboard new joiners through a continuous delivery pipeline
Meet weekly at lunch
Half-yearly performance assessments
He also provided four takeaways:
Everyone by default is good
Intrinsic over extrinsic
Engagement is your work responsibility
Let them lead
Uldis told an honest and open story about his journey with the hope it will help others. To hear it firsthand, watch it for free here. You can watch any of the 2017 AllDayDevOps sessions free of charge here.
On March 15, I gave four keynote speeches on DevOps in Toulouse, France. As the main speaker of Econocom Club MEP 2018, an annual think tank summit organized by the European business-to-business digital services provider, I shared the day with 15 firms in industries as prestigious as financial services, energy, aerospace, aviation, and telecommunications and heard all about their implementation projects.
The lessons learned from this year’s summit are troubling, they tell a story the vast majority of DevOps vendors aren’t prepared to hear: They miss their client expectations. There’s a severe disconnect between what’s expected and what’s delivered.
Participant visions and approaches didn’t surprise me; they simply confirmed my point that DevOps is misunderstood. By stressing the implementation of Continuous Delivery (CD) toolchains—selling technology is more lucrative than transforming a business—IT service providers aren’t helping.
What do these lessons tell, exactly? if you’re an open-minded leader who understands that a new IT service delivery paradigm more focused on business concerns is needed, this is for you.
The Untold Frustration
In his opening speech, facilitator Fabrice Berne was inspired to ask participants while they introduced themselves to share the purpose and challenges of their DevOps implementation project.
What I heard didn’t surprise me; it was a mix of fascination and frustration—participants were at the same time excited to work on a DevOps project and frustrated because they weren’t getting the promised business benefits.
“The reason is, you all tackled your DevOps project the wrong way,” I said. “You started by implementing the CD toolchain, thinking tools on their own will deliver the expected business benefits. That illusion is widespread in the IT community!”
So, What is DevOps?
As my claim turned the atmosphere icy, I added, “DevOps can’t be narrowed to these tools—not even to agile practices and automation. It’s more than that. DevOps seeks to make the business competitive, wealthy and healthy by continuously delivering high-quality software.” And concluding my introduction, I made it clear: “The fundamental question is, How is business value created? Many experts, particularly techies, struggle to answer it.
“Let me say this straight: Most DevOps projects fail because certain experts erroneously spread the idea that the most important piece of DevOps is the CD infrastructure,” I said, adding, “The fact of the matter is these experts and the IT solution vendors they represent are creating confusion; through massive marketing hypes they force CIOs to address DevOps through the distorted lenses of the so-called DevOps tools.”
The Inconsistent Disparate Visions
The following chart results from a survey we conducted at ITaaSNow last year. It involved 2,681 businesses that were unhappy with their cloud and DevOps migration projects; we wanted to show how poor DevOps approaches lead businesses to failure:
Figure 1 – Disparate and erroneous visions that cause implementation failure
“As you can see, there’s no homogeneous perspective right now,” I told the audience. “It varies according to the business culture, objective and strategy or the DevOps architect’s understanding, experience and expertise. In most cases, these customized visions are incomplete and generate no business value at all.”
I picked two failure causes in the chart to demonstrate my point.
Starting with the notion that, “automation is the core of DevOps,” I argued, “DevOps primarily seeks to help generate business value. Generating business value is about identifying market and customer expectations, translating expectations into profitable service ideas, developing, deploying, promoting, selling them and continuously improving customer experience.
“Where did techies get the idea that to make a business profitable the only thing to do is to implement Git, Jenkins, Cucumber and Chef into a CD toolchain?” I asked, somewhat ironically.
Picking a second cause, “DevOps strategy should only stress software development activity,” I continued. “Thinking that isolatedly software development activities will generate business benefits without involving marketing, sales, testing and operations is a pure illusion. Once again, generating business value is a complex process that covers identifying market and customer expectations, translating expectations into profitable service ideas, developing, deploying, promoting, selling them, and continuously improving customer experience.
“Where did solution vendors get the belief that, software development alone is enough to generate business value?,” I asked. “That’s another myth they nurture!”
I then warned: “Make no mistake about it: All the visions represented on the chart are either incomplete or wrong. They do not reflect what DevOps is. You must acknowledge once and for all thatit is a business transformation effort, not only an IT capability implementation. Period.”
The Contrast with the Founding Fathers’ Vision
“Who better than its founders can provide the right vision and definition of DevOps?” I asked.
In his article, Adam reminded us, “Becoming better at building and delivering software is the stake. It’s not an optional piece of their strategy: It’s the future of how their customers want to work with them. Software is table stakes for survival.”
He added, “But the real answer lies in looking at what John, Paul, and Jesse were doing in 2009—not in the specific technical choices they made, but the style in which they worked, the essence of what they believed made them high functioning and successful. … Then the challenge begins: how to apply this new style to businesses trying to become better at building and delivering software.
“DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible toward their goals. Tools matter. Make no mistake: Trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure.”
He concluded, “Fundamentally, it is about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.”
With Respect to Techies, DevOps is Primarily a Business Operational Model
“If you paid attention to what Adam Jacob reported about Jesse, John and Paul’s vision, you probably noticed that it emphasizes two fundamental elements of high-performing businesses: the well-known IT infrastructure and the unknown operational model,” I told the audience.
Moving to the next slide, I provided evidences to my point, “As the picture shows, DevOps, according to its founding fathers, isn’t the CD platform, automation toolchain or the platform-as-a-service (PaaS) infrastructure solution vendors and certain consultants would like you to believe.”
Figure 2 – The Founding Fathers’ Vision
The slide seemed to clear up a doubt about what the audience had been hearing. I confirmed, “With all due respect to my fellow techies, as I’ve been implementing it, DevOps transcends software development issues; it’s a business operational model supporting your company’s competitiveness.”
Figure 3 – DevOps as the Business Value Chain
I told the audience I chose to represent it as a two-component system “because I wanted to make sure IT professionals and business leaders understand that implementing DevOps is primarily a business transformation effort for optimizing the organization’s operational model and IT infrastructure.” I added, “The operational model is the subset of interactions, staff and skills, processes and practices, values and beliefs, and tools that’s repeatedly mobilized across your organization to generate the expected business benefits. It’s where all its value propositions and competitive advantages—organizational agility, flexibility and velocity, innovation culture, more like it—are created. As (fellow speaker) Stephanie Carton puts it, the operational model is where DevOps culture is implemented.”
Anticipating the audience’s reaction to that point, I said, “It doesn’t mean CD toolchains are useless or doesn’t bring value, without them we’re dead. The point here is, business benefits result from an optimized operational model enabled by a well-engineered CD toolchain.”
I’m not the first one to go against the techie perspective of DevOps, I warned. “Ernest Mueller in his fantastic, “DevOps: It’s Not Chef and Puppet,” raised the red flag.” His message is clear: “If someone has a systems problem, and you say that the answer to that problem is Chef or Puppet, you understand neither the problem nor the tools.”
The Near Future of DevOps
In the first part of this article, I wanted to share with you the clarifications I made and more importantly, re-establish the truth on messages as erroneous as “DevOps means CD toolchain and Agile practices,” and “CD infrastructure or software development on its own creates business value.” They’re misleading CIOs and are taking hundreds of projects straight into the wall!
Figure 4 – DevOps Big Picture
In part 2 of this article, next month, I’ll tell you what we debated about the near future:
Why Agile and Lean practices will boost business competitiveness?
What is ITaaSNow DevOps Capability Maturity Model (CMM)? How does it enable continuous business performance improvement?
What is Artificial Intelligence for Operations (AIOps)? Why will it make DevOps the cornerstone of businesses’ digital strategy?
Stay tuned!
The Key Takeaways
This what I wanted to tell you about DevOps as we discussed it. The key takeaways are:
DevOps isn’t narrowed to agile practices and CD toolchains. Don’t fall into the trap of certain solution vendors who tell you that Git, Jenkins, Cucumber, Chef, Containers and microservices will boost your business performance. It’s false; things aren’t that simplistic.
DevOps combines an optimized operational model and a CD platform to bring together marketing, sales, post sales, software development, testing and operations into an application delivery capability that boosts your organization’s competitiveness.
Starting the CD toolchain implementation without optimizing the operational model is the surest way to take your DevOps implementation project into the wall.
DevOps implementation is primarily a business transformation effort, not just an IT capability deployment effort.
What matters isn’t applications and digital services delivery at the speed of light, but the timely delivery of added-value applications and digital services to the right market segments and business users.
According to Econocom’s feedback, most participants are reviewing their DevOps implementation strategy; they will make their operational model optimization the priority. Mission accomplished!
Hackathons are a great way to demonstrate the value of a platform. I had the chance to speak with Malcolm Ross, vice president, Product at Appian to share a bit more about Appian’s virtual hackathon to correspond with its upcoming user conference.
Full disclosure: I’ll be one of the judges attending Appian World to judge the finalists, so hope to see you all there!
Alan Shimel: Can you share a high-level overview of the Hackathon?
Malcolm Ross: Appian is holding its first online hackathon in conjunction with DevPost to correspond with our upcoming Appian World conference in late April. We’re looking forward to seeing how participants are able to build and deploy powerful enterprise apps with Appian’s low-code cloud development platform.
Shimel: Who could apply for the Hackathon?
Ross: Whether they’re an existing Appian customer or not, we challenged anyone to build a new app on the Appian platform that enables their business to do more. There’s no specific theme—just show us something that improves their team’s performance and drives enterprise innovation! We asked all participants to submit their applications by March 27 along with a demo video (hosted on YouTube, Vimeo or Youku). This should incorporate a step-by-step visual demo, and additionally, a way to access the working application for judging and testing. Anyone interested in participating received a free 60-day instance of the full Appian Cloud platform to support their development efforts.
Shimel: Who judges the winners?
Ross: A panel from Appian will score all eligible submissions to determine the top three finalists. Finalists will be notified by April 13 and given the opportunity to demo in-person or remotely to an all-star panel of judges, including Apple co-founder Steve Wozniak, Forrester analyst John Rymer and yourself, Alan! We’ll also have some Appian executives involved in the process including Senior Vice President for Strategy Lang Ly, Chief Technology Officer Michael Beckley, Director of Product Strategy Jorge Sanchez and myself.
Shimel: What are the evaluation criteria for the selection of the winning team?
Ross: It’s pretty open-ended for participants to come up with their own innovations. The main requirement was that the users must build a functioning app on the platform by March 27. More about the criteria can be found here.
Shimel: What are the awards?
Ross: There are three cash prizes ($5,000, $3,000 and $2,000) along with admission to Appian World 2019 and promotional of the submissions by Appian on the Appian AppMarket.
First place will receive $5,000 cash and four free passes to Appian World 2019, and the Appian Deluxe Promotion, which includes a featured promo on Appian.com, Appian AppMarket (if the app is in the market) and Appian Community, joint webinar and collateral, a blog post on Appian.com and a press release.
Second place will be awarded $3,000 cash and two free passes to Appian World 2019, and the Appian Promotion, which includes a featured promo on Appian AppMarket (if app is in the market) and Appian Community and a blog post on Appian.com.
The third-place prize is $2,000 cash and one free pass to Appian World 2019, and the Appian Promotion, which includes a featured promo on Appian AppMarket (if app is in the market) and a blog post on Appian.com.
Shimel: What is the timeline for the Hackathon?
Ross: As mentioned, the deadline for entry was March 27. We’ll make sure to notify finalists by April 13 so they have some time to book travel if they would like to meet our all-star panel of judges for the conference. Final judging will be held on April 25 at the Fontainebleau Hotel in Miami Beach, Florida.
Shimel: Where can people find more information about the Hackathon?
Ross: Anyone who’s interested can find more information about Hackathon at Appian.devpost.com or learn more about our Appian World conference at appianworld.com.
Intel IT’s Enterprise landscape is highly complex and diverse. The Enterprise Change Management team has the responsibility of managing the changes in this landscape, which is of the order of hundreds of changes every week. On one hand, we had to make sure we keep the change management processes stringent so that defects/major incidents did not happen in the production environment, leading to productivity loss, shipment delays or cost impacts. On the other, there is a need to assist the capability teams to land changes into production faster than ever to meet their dynamic business demands.
A challenge that many global IT organizations face is, How do we adhere to ITIL processes while teams transform into agile/DevOps way of working? In other words, how do we manage the two seemingly conflicting goals from two different IT organizations, one focusing on the agility of the development and measuring the success of the projects by their throughput time and the other measuring the success by the quality?
In the IT enterprise, the quality is measured by the number of change induced incidents in production—incidents that are caused due to change(s) landing in production. Our team had a challenging goal of keeping it to zero! The year 2017 started with this million-dollar (or is it worth more than that?) question: How do we meet this goal while not impacting the speed of the agile teams? We came up with an agile solution. A DevOps solution for the DevOps problem sounds logical, right?
We formed a scrum team to address this problem with the theme, “Simplify and automate, keeping the focus on quality, velocity and productivity.” The scrum team had change management process owners and the representatives from all the development technologies. The chart below summarizes the steps followed:
Simplify and Automate, Keeping the Focus on Quality, Velocity and Productivity
The first sprint was all about getting the alignment. As much as the number of teams that follow agile, as many definitions of agile exist! The focus was to demystify the myths about agile as well as ITIL change management processes. At a glance, processes look incompatible with Agile, but the goals are the same. Both aim to add business value incrementally in a continuous manner without disrupting the operations. They are not contradictory but complimentary.
Subsequent to this alignment, the second sprint went to the details of the enterprise change management process that’s in place. The process was broken down into the lowest level of details based on the 5W and 2H’s (who, why, what, when, where, how, how much). For example, there are process requirements from legal standpoint that are non-negotiable. There are certain processes required to ensure architectural compliance. We also acknowledged and aligned on some of the challenges and the time taken for process adherence. Multiple discussions happened in this space and it helped all of the teams to come to a common understanding on why these process requirements exist. Process swim-lane categorizing all of these aspects was internalized as part of this sprint.
Change Management Process Swim Lane
The third sprint got things into action mode. Each of those process steps was identified for potential simplification and automation. They were further classified as short-term and long-term based on the automation efforts on continuous integration/continuous delivery (CI/CD) that were underway. The development teams were shown the flexibility and empowered to meet the process need by way of automation rather than completing a manual checklist for every change. This way of policy and rule-based automation helps in a longer way in integrating ITIL Change Management and DevOps.
All along these three sprints, process improvements were rolled out. Several automation efforts were launched. Objective risk assessment enabled us to identify changes that required advance communication to all segments. Multiple gate approvals were reduced into only two—one when the development starts and later before it goes to production. Test cases and results from the CI/CD tools were used effectively to replace documentation.
Process refresher and engagement sessions were held across the organization to share the improvements, gather feedback and incorporate them into further sprints. This helped to gain the confidence of various teams and made the journey further better.
Now the focus is on continuous improvement, which is to implement all those action items identified and also keep them updated as other factors change in the internal and external environments. Engagement between theAgile/DevOps teams and the change management teams are getting refined based on the scrum development models. The success of ITIL Change Management and DevOps integration relies on calling out the agile process followed for the project and having the right engagements at the right points in time. The below picture depicts the engagement in a simplistic manner:
Scrum and Change Management Intersection
The efforts yielded fruits and the organization met the goal. The number of change induced major incidents was ZERO for the Enterprise Segment for the whole of 2017. We need to remember that these process improvements were done without impacting anything underway; it was akin to servicing a flying aircraft in the middle of the sky. The feather in the cap was the positive feedback from the ERP vendor: “The change control process at Intel has become very agile in recent years, with transports to production now occurring nearly every day of the year. … In general, we do not consider such frequent changes to Production to be desirable due to the risks involved; however, Intel appears to be managing the process well as the quality of transports is closely monitored.”
References:
ITIL® Service Management v3
The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim, Jez Humble, Patrick Debois & John Willis
According to Forrester, 64 percent of businesses are dissatisfied with the time it takes to release new features for customers. Brand loyalty has given way to customer loyalty; to drive it, organizations must focus on customers and their experiences using their products and services.As a result, organizations of all sizes need to make customer experience their highest priority.
To many business leaders, the speed of rolling out new updates is the most important part of satisfying customer expectations, maintaining customer loyalty and staying ahead of the competition. At the same time, user expectations for fast and reliable digital experiences across platforms continue to increase. As a result, development teams are pushing out service updates faster than ever before while trying to minimize any degradation of the experience as they move at a quickened pace.
But with heightened and persistent focus on rollout speed, it is easy to forget that the overall user digital experience is critical to maintaining customer loyalty. Businesses must integrate their focus on performance testing with their DevOps workflows to make sure speedy product rollouts don’t come at the expense of customer experience. So how should businesses ensure strong delivery processes to both improve customer experiences and drive efficiency in the application development and delivery pipeline?
Performance Starts with Constant Measurement in Unit Testing
DevOps, as does Agile, breaks down testing into smaller chunks. Each new rollout has an iterative impact on the application or website. Whether good or bad, the results stack up. Customers may demand certain new features, but user experience will suffer if each update that meets that demand slows down the application more and more over time.
Testing these units is very important and setting performance SLAs per unit per build is the first step to a performance culture. Organizations with a mature performance culture will turn back code if it doesn’t meet their performance SLA, keeping it from ever reaching QA.
This is Not an Either/Or — It is an And
DevOps teams are very good at rolling out rapid iterations of products and features, but without careful consideration, the pace of those updates can build momentum for digital experience failure. There are false positives in DevOps testing. With unit tests constantly passing, it’s easy to lose sight of the bigger picture. It’s not the fault of the DevOps engineers or QA; they are working within an established process that is designed to sniff out errors on a per-build basis. But what happens when you put it all together? Organizations start to forget about end-to-end testing and can see failures when the application is stressed by heavy demand, when it really matters during critical business events like Black Friday, live sporting/news events, product launches, or changes in financial markets. Teams implementing DevOps-style testing must remember to test all the “units” working together end to end. This needs to be part of the DevOps workflow but is often being forgotten.
What You Can’t See Can Hurt You
Testing for performance in the development lab can help mitigate some of these performance issues before they get out in the wild. But it’s overly optimistic to think that you’ll catch everything. Delivery teams need to constantly maintain visibility in the real-world use of their applications with real-time real user monitoring to alert them of any degradation in the experience during or just following a release. A quick response can help mitigate a larger detrimental impact to the business, and the fidelity of real-user data gives assurance there aren’t any blind spots so you can fail fast, and shorten time to resolution. The web is a wild place, and users have sneaky ways of finding their way into and through your app that you may not foresee when building your test plan. You can use this real user data that you’ve collected while monitoring to create more realistic test plans that will truly replicate real-world browsing behavior.
This data can also inform the development team about the impact of design decisions on performance in each new update. They can prioritize which parts of the site or app to fix based on what would be most impactful to the business and weigh that against plans to build out new features aimed to enhance functionality. The key factor is an understanding of the business impact of performance and using that to guide and prioritize development resources to achieve the best possible results.
Adopting a methodology to monitor, optimize and validate ongoing enhancements to your application can help with the continuous improvement of user experiences and give your development efforts a customer focus. DevOps teams have a responsibility to the user experience and should consider how it correlates to business impact. Faster time to market is important, but as important is making sure the customer experience continuously improves as well. Uniting cloud delivery with DevOps workflows and keeping performance in mind will put your business on the path to ensuring both faster rollouts and superior user experiences.
We may not have fleets of robots waiting on us hand and foot yet, but the automation revolution is in full swing. With automation becoming more apparent in daily life, some of the misguided fears over the concept and its potential to eliminate jobs are slowly being replaced with the view of automation as an opportunity. And given that IT departments are powering today’s businesses, few can capitalize on this opportunity more than enterprise IT.
Across industries, the pressure to deliver innovation faster continues to grow, and with budgets and headcounts remaining relatively stagnant, organizations not adopting an automation strategy are being set up for failure. Automation allows computers to do the mundane tasks—and increasingly, even the not so mundane—freeing staff to focus on innovation.
Automation Everywhere
While 2017 demonstrated that automation is key to IT optimization and digital transformation, 2018 will be the year IT automation truly hits its stride, with widespread, systematic adoption across industries. So what trends in automation should organizations be looking to embrace next? These five areas in enterprise IT are prime to be automated in 2018:
Networks
Networks are arguably the bedrock of enterprise IT, yet true automation of the network stack has been nearly nonexistent. In fact, managing networks hasn’t changed significantly in the past 30 years. Network engineers still are logging in to individual devices and hand-crafting configurations, leaving network teams increasingly isolated from the DevOps revolution and slowing digital transformation.
This year, network automation will move full steam ahead in the enterprise—and there isn’t really an option for it not to.
With the ongoing march to cloud, new and potentially massive IoT deployments and increased pressure to modernize internal IT for efficiencies, network engineering must have the same focus and attention that server and app engineering has had in recent years. Network teams cannot remain isolated and resigned to merely maintaining the status quo; we should embrace them and show them how to reap the same benefits combining Dev and Ops has provided.
Bringing the automation of networks into the fold of DevOps will enable tasks to be executed with increased cadence and with a higher degree of accuracy, while increasing collaboration between teams that are critical to the success of modern application architectures.
Infrastructure
To run business systems, you need infrastructure, and that infrastructure must be set up to have an impact on an organization’s day-to-day operations. Regardless of whether your systems are running in the cloud, virtualized environments, containers or on bare metal, if you still have to configure and provision infrastructure manually, you are moving too slow. Weeks or even days to provision systems means holding up changes that your business needs.
While automated provisioning has been around for a long time, in 2018 we will see this amplified, primarily due to the ease of use of automation tools and platforms. With automation, infrastructure can be scaled automatically or, using precanned scripts, an operations engineer can quickly affect hundreds or even thousands of devices. This type of technology will allow IT departments to rapidly expand their infrastructure without expanding manpower.
Once automated provisioning takes over the heavy lifting, focus can move to automating management, maintenance and troubleshooting.
Microsoft
Traditionally, in the enterprise, Microsoft environments have been managed by discrete teams. Recently the company has been doing a great job of helping users learn from wider experiences within the industry (joining the open source initiative, for example), and it’s helping break down some of the walls within IT departments. Microsoft also has focused on enabling Azure-backed services in the enterprise, offering more opportunities for customers to adopt automation.
With SQL Server accelerating in popularity—helped by installs on Red Hat Enterprise Linux as well the traditional base of Windows—automation is an opportunity to ease some of the traditional burdens of scale. We’re already seeing open source development of SQL Server Ansible modules, which is only going to help fit this piece of critical application infrastructure into DevOps-style workflows.
Microsoft has also taken a broader interest in open source projects. This has included contributing to the Ansible community, helping users integrate open source projects with their Windows environments.
Security
Make anything simpler and easier and it is far more likely to be adopted. Over the last 25 years, the connection of our lives to the internet has only increased complexity. This complexity has made it more difficult for security professionals to keep us all safe.
With configuration management, we’re able to build security in from the start rather than as an afterthought. Changes can be logged and enacted rapidly, giving us the ability to respond to incidents in a timely manner—even across massive scale.
As our colleagues in cloud and networks have automated more, they’ve reached new levels of scalability. This year we’re already seeing growth of the DevSecOps movement, and expect it to continue. When we bring systems and processes together with automation, doing so securely becomes easier.
Orchestration
It comes as a surprise to no one when we say modern applications are complex. They comprise the latest technologies as well as legacy systems. They run in the cloud, across multiple databases and need to be accessed from a variety of devices. This makes it exponentially harder to determine root causes of issues, let alone tell these resources what to do. Since application performance can impact a company’s bottom line, maintaining it is a top priority. However, performance tuning often can’t be an IT team’s full-time job.
Orchestration is the automation of processes. It delivers relief from the administration, monitoring and help-desk chores that eat up time and resources. IT teams can define how an application is supposed to behave in its running state, and orchestration can bring about that bigger picture. Orchestrated automation is what will really set companies apart from one another, allowing teams to deploy applications quickly and reliably with an easy maintenance path ahead.
Ross: Whether they’re an existing Appian customer or not, we challenged anyone to build a new app on the Appian platform that enables their business to do more. There’s no specific theme—just show us something that improves their team’s performance and drives enterprise innovation! We asked all participants to submit their applications by March 27 along with a demo video (hosted on YouTube, Vimeo or Youku). This should incorporate a step-by-step visual demo, and additionally, a way to access the working application for judging and testing. Anyone interested in participating received a free 60-day instance of the full Appian Cloud platform to support their development efforts.
