devopsy.kinsta.cloud

Tag: devops

How DevOps Can Help Speed Go to Market
With continuous evolution of IT systems, speed and flexibility have become of paramount importance for businesses. This requirement has caused a massive shift in the IT delivery system. Now, building and releasing a better product in the market is not enough for businesses to stay ahead of the competition. Organizations need an agile approach to understand and adapt to information, trends and new developments, and to meet the demands of time-to-market features.

DevOps is one such cultural shift in the IT field that shows how software development and IT operations can work together to reduce time to market. It has attained such a great profile in the market that people have started measuring the outcomes for businesses that adopt it.

If you’re just beginning with DevOps, here are some tips that will help you understand how you can accelerate time to market for your product and services.

How Can DevOps Accelerate Time to Market?

There are many ways in which DevOps helps organizations accelerate time to market for their product. Some of the most effective ways are:

Faster Delivery of Features and Modifications

When development teams build software, they connect with IT operations to send the software for testing. If the product is completely new, operations need to create a testing environment. If the software is an updated version of the current product and there is already a testing environment for it, operations still need to configure and add interfaces and side applications. So, a developer can only deploy code to the software when the operations team tests the product, which is a very time-consuming process.

However, DevOps eliminates such time-consuming tasks from the software development process. For example, with automated testing of web apps developers get quick feedback and automated integration allows them to make changes in the code base more quickly. Therefore, organizations can release small or incremental updates of the software while delivering new features to market faster.

Enhance Efficiency

DevOps encourages development teams to give more time to value-creating work. When businesses use automated testing and integration, developers don’t have to waste their time waiting for machine configuration or code integration. Both tasks can be achieved by clicking a button on the self-service portal.

For example, many European banks have implemented DevOps in their software process, which resulted in 25% efficiency improvements in providing updates for their online banking applications. It also reduces the workload for the IT operations team so that they can work on more challenging tasks to add more value to the company.

Improved Quality Code and Quick Recovery from Failures

When software is released to the market, developers often start working on their next project. So, they usually don’t have any motive to predict or prevent future problems related to software; it’s all up to the operations team. But DevOps keeps developers involved during the entire life cycle of a software product for updating any feature or application, which results in improved quality code. Also, it requires only a few fixes as developers can track and eliminate potential problems while writing code.

As developers work with smaller chunks of code, when a failure occurs in any product, bugs can be tracked easily to their resources. Also, human errors are reduced thanks to the automation that DevOps provides to the software life cycle, while allowing companies to deliver fixes faster.

Best Practices for Using DevOps

Just like agile approaches, DevOps doesn’t have any pre-planned implementation model. But, most companies that use DevOps follow these best practices:

Set a Business Standard

The improvements in an organization can never be measured without having a business standard. If you want to reduce time to market for your software development process, then have a look at the current development process and find out which areas need improvement. For example, you can review the steps involved in making a project live and identify any defects, inefficiencies and constraints in the project.

After reviewing these processes, you can set a business standard that shows the current software development process and the improvements that are required to reduce the time to market. With DevOps, you can set a business standard more quickly and improve your software deployment process.

Optimize and Eliminate Unnecessary Inputs

While reviewing your software deployment process, you might encounter some inputs that don’t add value to the process and reduce its speed. Eliminating such inputs from the development process is crucial, but make sure there is open communication between you and your team so efforts are not wasted.

What you can do is set up the right team structure and use tools that provide transparent and fast communication between the teams. For example, you can structure a team that includes marketing managers, right analysts and, most importantly, DevOps resources.

Allow Continuous Deployment in Software Process

Continuous deployment is one of the essential key factors of DevOps that helps in reducing time to market. It is the continuous delivery pipeline that doesn’t involve any manual intervention in-between. In continuous deployment, automation stimulates and simplifies communication and validates the software process to ensure timely releases.

However, not every company implements continuous deployment in its software development process. Usually, the organizations that need to move faster to provide new features, applications or security channels for their product use continuous deployment. For example, media companies and online retailers use continuous deployment in their software development process.

Improve the Quality of Automated Tests

One straightway to reduce time to market with DevOps is improving the quality of automated tests. In any organization, testers test the application for its functionality and other factors. But this testing process can be enhanced by engaging with clients and a targeted audience in the development process. Taking input on the overall functionality and user interface will not only improve the testing process, but also help you find bugs and defects earlier.

It is proven that if bugs are not tracked and eliminated in the early stages, it can greatly impact the time to market for your software product. For example, if you want to test your web application browser compatibility, then consider cross-browser compatibility testing. With end-to-end automated testing, the overall testing process can be improved, which will result in reducing time to market. Some other benefits of automated testing that can improve your DevOps are:
- Track and eliminate bugs and errors in the early stages to improve the system’s capacity.
- Improve the security of your software product.
- Enhance custom engagement and satisfaction with a high QoE score.
- Less cost of ownership.
- Meet the industry standards and compliance regulations in a better way.
An improved automation strategy helps move your product to market faster and allows your resources to do more high-value tasks. Also, the development teams will be more encouraged and confident to add new features to the application, as it will be tested more thoroughly.

Conclusion

Today’s businesses heavily rely on applications to collaborate, communicate, complete sales and operate more proficiently. Therefore, they strive to bring these applications to market more quickly so they don’t miss any opportunities and easily adjust to the market standards. To achieve these objectives, organizations must adopt the right DevOps practices in their software development processes to reduce time to market.

— Junaid Ahmed
May 1, 2019
Dell Technologies Drives Automation Deeper into Platforms

Dell Technologies this week launched a series of initiatives intended to provide IT organizations with multiple deployment options for Dell EMC appliances and servers, including forthcoming managed service offering through which Dell will manage private cloud platforms based on VMware software on behalf of customers.

Announced at the Dell Technologies World 2019 conference, Dell EMC also unveiled a new appliance series and revealed an alliance with Microsoft under which its VMware arm will make available cloud software on the Microsoft Azure cloud, in addition to existing support for Amazon Web Services (AWS), IBM Cloud and servers deployed on-premises.

Jon Siegal, vice president for product marketing for converged platforms and solutions at Dell EMC, said Dell EMC plans to make it easier for IT organizations to consume IT infrastructure in an on-premises IT environment as a service or continue to use their capital budgets to acquire servers and appliances.

To advance that latter approach, Dell EMC is launching VxFlex, a set of appliances that include an operating system that enable compute, storage and networking separately. In contrast, the existing VxRail series of appliances are optimized for VMware and assume compute, storage and networking will be scaled in tandem, said Siegal. Dell EMC is also now unifying a set of hyperconverged appliances and converged infrastructure servers under a common VxFlex brand, and Siegal said in the future those offerings will be extended to add support for Kubernetes alongside platforms from vendors other than VMware.

At the same time, Dell EMC is previewing a VxRail Analytical Consulting Engine (ACE) that will be embedded in VxRail HCI system software that Dell EMC provides in its appliances optimized for VMware. That analytics engine employs machine learning algorithms to maximize application performance, while also providing self-optimization recommendations and capacity forecasts.

The Dell Technologies Data Center-as-a-Service offering, meanwhile, is scheduled to be generally available in the second half. It marks the first time Dell has launched a managed service under its own brand. VMware, however, has been providing managed services for the past year. The Dell Technologies Data Center-as-a-Service offering extends that concept to include Dell EMC VxRail appliances.

Automation is clearly at the heart of the evolving Dell Technologies strategy. The challenge organizations that have embraced DevOps will face is aligning their processes with the automation frameworks Dell Technologies is embedding in both VMware and the underlying infrastructure on which VMware gets deployed. To address that issue, Dell Technologies over time will bundle frameworks such as the open source distribution of the Pivotal platform-as-a-service (PaaS) environment from Pivotal Software, an arm of Dell Technologies, on its platforms, Siegal said.

These moves signal Dell Technologies is trying to fulfill a promise to make it as easy to manage IT infrastructure deployed in an on-premises IT environment as it is to manage on a public cloud. There’s obviously still a gap. But as Dell Technologies starts to make IT infrastructure available as a service, it may one day become challenging for DevOps teams to tell where any one cloud happens to be running at any given moment.

— Mike Vizard

April 30, 2019
Embedding Accessibility into the DevOps Process

Calls for accessibility and inclusion are a defining characteristic of current times. Persons with disabilities (PwD), including vision, hearing, cognitive and physical impairments and others, are demanding equal access to virtually all public services and forums they interact with, from transportation to banking and self-service terminals in airports—and increasingly, digital (web and mobile) services.

Ensuring accessibility can help enhance brands and is good business practice. The process can seem daunting but integrating accessibility into DevOps doesn’t have to be overwhelming. There are several simple steps for getting started.

Understanding Your Organization’s Unique Accessibility Motivators

Knowing what accessibility elements you need to test for depends on numerous factors, including your industry and where you are located. For example, U.S. government organizations are subject to Section 508, while telecommunications providers must comply with the Communications and Video Accessibility Act (CVAA). Different scenarios require a nuanced approach to accessibility testing.

The risks of digital inaccessibility are growing far beyond government websites, with the number of Americans with Disabilities Act (ADA)-based web accessibility lawsuits increasing 181% between 2017 and 2018. Since the beginning of this year alone, several well-known brands including Domino’s Pizza and Beyoncé have been sued for web accessibility breaches, bringing the issue to the forefront.

E-commerce sites are often more concerned with lost revenue opportunities, as the average blind person is known to abandon several companies per month due to web inaccessibility. For transaction-oriented sites, inaccessibility translates directly to lost business. Whatever the motivators, building empathy can be a great way to give this mission meaning for developers. Organizations can do this by staging and having developers participate in “empathy events” where simulations are offered and developers can experience first-hand what it’s like to interact with a given website using the same assistive technologies that people with disabilities rely on regularly.

Set Achievable Interim Milestones

Agile DevOps teams emphasize catching defects as early as possible in the software life cycle to ensure efficient, high-quality rollouts. Unfortunately, accessibility testing is often relegated to the end of the process or performed as user-acceptance or usability testing. This type of testing is often manual and can be resource-intensive and expensive.

Organizations only became aware of issues upon hearing from end users encountering problems—or, worse, taking legal action to gain equal access to web-based content and services.

Getting from a manual process to a fully automated and integrated process takes time. We recommend setting achievable, interim milestones that start small and build on early success. Organizations may not know what to tackle first, but some commonly shared examples of achievable first milestones are accompanying all digital videos with subtitles and/or sign language translation (for the hearing impaired) and ensuring that all new UIs are clear of any issues identified by automated tools. Experts and trainers can offer valuable advice on addressing the basics and then building on the success.

Implement Tools

Today’s developers have easier access to more comprehensive accessibility testing tools than ever before. Currently there are tools available for all the major platforms (web, Windows, Android and iOS) and many of these have been open-sourced, making them richer every day. Interactive testing functionality can enable development teams to thoroughly assess the accessibility of products early on in the cycle, while libraries allow these tests to be run regularly as part of the development test automation. A good tool will provide developers with simple remediation guidance and allow them to embark on a learning journey to increase their knowledge and expertise.

Measure, Improve and Automate

Ongoing measurement is the key to understanding whether your accessibility transformation is taking hold. Leading metrics will focus on the change in development practices. These changes will give early indication of end user outcomes. An example of a leading metric is “percentage of new UI code that is clean from an automated testing perspective.”

End user outcomes, while lagging, are important to ensure that the activity is leading to real change. An example of an outcome might be the number and the change in the accessibility-related call center inquiries. A reduction would indicate that fewer accessibility issues are making their way into production. Metrics are strongest when they are presented in a manner that directly correlates to business outcomes (such as customer satisfaction), as these tend to resonate the most with business executives, which helps build the broadest internal support base.

Once you’ve had some early successes, it’s time to expand, and you can keep tackling issues incrementally. Organizations should also focus on continually shifting accessibility testing “further left” earlier in the development cycle to enhance quality while maintaining velocity. The sooner you detect and fix accessibility issues, the less likely these are to become more deeply baked into the software, making them more difficult and time-consuming to undo.

Organizations also should consider replacing interactive and manual accessibility tests with fully automated tests. While manual testing cannot be completely eliminated, automated unit testing and integration testing enable developers to test for accessibility as they code (not after the fact), while automated regression testing ensures live web content and applications stay accessible after changes are made. Automated regression testing is critical for organizations wishing to ship software often while maintaining quality—in some industries such as financial services, a disproportionate number of websites have experienced some level of accessibility regression.

Conclusion

DevOps teams are focused extensively on maintaining exceptionally high levels of software quality combined with velocity. We’ve become obsessed with minimizing the number of bugs that make it into production but may be overlooking one of the key attributes of high-quality software—accessibility.

In most cases, functional testing does not cover accessibility testing. While functional testing determines whether a system is working as expected (i.e., certain inputs generate certain outputs), accessibility focuses on ensuring usability for PwDs as a non-functional attribute. With estimates that the current number of PwDs in the U.S. nearly equals the total populations of California and New York combined, accessibility testing needs to be prioritized in the same way as functional testing. Otherwise, you are shutting these people out.

In summary, organizations that demonstrate a commitment to accessibility through their digital products and services will have a natural advantage in an increasingly competitive market space. Getting started can be relatively simple, and you should focus on motivating development teams to achieve and overachieve, emphasizing continual improvement rather than perfection from the get-go.

— Dylan Barrell

April 30, 2019
‘DevOoops’ Moves: Unforeseen Lock-Outs
DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by Carlos Sanchez, principal software engineer, about unforeseen lock-outs.

Scenario:

When you’re automating deployments using configuration as code, make sure you have the right protections in place (i.e., validation of configuration). Otherwise, it’s easy to lock yourself out, forcing yourself to manually log in to each machine to fix it when a bad change is pushed and deployed to all the machines.

Having a strong technology solution that securely and centrally stores credentials for the names of people who access those machines is critical to maintaining a successful DevOps program. It’s a no-brainer. When you have to service accounts, you’re much more likely to be able to leverage a fast-acting script to log in and reconcile logouts if credentials are centrally stored than if you had eight individually managed service account-based credentials.

How do you reconcile lock-outs? How do you avoid the kind of DevOoops situation that can derail all of the good progress you’re making? The process you adopt will depend on what your software development and deployment life cycles look like. Here are several potential approaches:
- You can use multiple staging and preproduction environments that share common configurations with the production environment. This sets up a process where, before you try to deploy an app or a new configuration to your production environment, you know you have successfully deployed it to environments that are as close as possible to production, multiple times.
- You can have post-deployment validation scripts run after every deployment and have them validate things such as, Can account X log into environment Y? The scripts should include common or leading indicators of success or failure of a deployment. Once artifacts have been deployed and the system starts, every deployment will immediately run these scripts as part of the deployment process. So, every part of the deployment is automatically validated as success or failure.
When taking an approach such as rolling deployments, you also need to ensure that broken configurations are identified before they’re propagated across multiple servers or server clusters. This means you need to validate your deployment and your configuration changes before you go to production, validate deployment and configuration changes on first deployment and then validate, validate, validate at each subsequent step.

By doing all of this, you avoid surprises. You extend a quality-first, continuous validation approach beyond just your application code and apply that to your environment. Avoiding unnecessary lock-outs will help you mitigate risk, eliminate wasted time and avoid bad customer experiences.

Takeaways
- As you bake quality into the processes and shift automation left, you need to make sure you validate all changes early and often.
- Organizations need to implement proper processes, not only for application code changes but also for infrastructure as code changes that manage environments.
- In automating in pursuit of DevOps, it’s necessary to have a strategy for credentials and secrets management of permissions for your DevOps and production systems.
— Brian Dawson
April 30, 2019
Mirantis Adds Modeling Tool to Configure Private Cloud

At the Open Infrastructure Summit conference, Mirantis today unfurled a software-as-a-service (SaaS) application through which IT administrators can employ modeling tools to configure private clouds based on either OpenStack or Kubernetes.

Boris Renski, chief marketing officer for Mirantis, said rather than having to manually configure a private cloud for an on-premises IT environment using YAML files, the Model Designer for Mirantis Private Cloud enables IT administrators to configure a private cloud using modeling tools they access via a graphical interface (GUI). The Model Designer is scheduled for general availabilility in May.

That approach then makes it feasible for IT administrators with little to no programming expertise to quickly spin up private clouds within the context of a DevOps environment using a set of declarative tools, added Renksi.

Those tools also enable IT administrators to specify the degree of configurability they require. A basic configurability level automatically populates most of the cluster settings to a default set of pretested values. The most advanced “ultraviolence” configurability setting enables IT administrators to adjust virtually every aspect of their on-premises cloud. The resulting configuration models are then fed into DriveTrain, which is the automation framework that Mirantis provides within Mirantis Private Cloud.

Renski said requiring IT administrators to master all the nuances associated with managing YAML files to stand up a private cloud is one of things holding back adoption of both on-premises private clouds and the best DevOps practices that should be relied to mange them. Most organizations that want to make the transition to DevOps clearly want to be able to manage infrastructure as code in much the same way public cloud service providers do today. The challenge is, the learning curve associated with achieving that goal is simply too high for the average IT administrator, he said, adding a modeling tool made available as SaaS application will make it possible for even mere IT mortals to easily spin up a private cloud within an on-premises IT environment.

Both OpenStack and Kubernetes suffer to varying degrees from often being too complex for the average IT organization to set up. Because of those complexity issues, adoption of both platforms often is limited to IT organizations that have advanced IT skills. But as the deployment processes surrounding both platforms become more automated, it’s probable the number of organizations adopting either platform will increase. At the same, IT organizations that do embrace either platform more likely will spin up more instances once they no longer have to rely on a cumbersome manual set of processes.

Of course, setting up a private cloud based on either OpenStack or Kubernetes is only the beginning of the IT challenge. Once all those private clouds are deployed, IT organizations need to acquire the tools and expertise required to manage them on an ongoing basis. In fact, one of the things IT organizations should consider in the age of the private cloud is the level of integration of the tools from vendors they intend to rely on to set up and then manage a private cloud.

— Mike Vizard

April 29, 2019
SREs: The Happiest – and Highest Paid – in the Industry

According to the 2019 StackOverflow survey completed by 90,000 developers around the world, whether you are already a Site Reliability Engineer (SRE) or thinking about becoming one, looks like you are onto something.

SREs, also called DevOps specialists, are a pretty unique type of talent; one that has knowledge in both software development and system infrastructure. And because the world of infrastructure is so vast, these professionals also need to juggle networking, security, system administration, hardware and anything else that could make an infrastructure unstable or down (yes, I am looking at you, A/C). That makes any day at work unique.

SREs, for the most part, are in charge of making sure that your favorite website apps are loading, and fast. Their work is not customer-facing but highly critical. According to Gartner, the average cost of IT downtime is going anywhere from $5,600 per minute to—when you work for Amazon—$2 million for every minute down.

That’s one of the reasons why SREs are among the highest paid in the industry, well, right behind their fellow managers! They also rank among the ones with the most coding experience—it takes time and hard work to get there.

And all of this leads to happiness! With an interesting job and high pay, SREs satisfaction is among the highest in the industry, and they rank in the top three of the ones not actively looking for a job. SRE for a day, SRE forever!

But here’s the problem: There aren’t a lot of SREs out there and hardly any computer science programs cover the topic. A recent tweet from Target software engineer Jessica Schalz illustrates the point very well:

As TechRepublic reported, these professionals are among the most wanted in the tech industry and 33% of IT leaders report having a hard time hiring profiles with these skills. A potential reason for this lack of talent might come from the fact that the profession is failing at attracting about half of our population: women. SREs are 30 times more likely to be men than women. Training non-bearded SRE talent is possible. The Holberton School, a coding school I co-founded where 40% of the students are women, is leading a lot of students to be hired as SREs.

And the good news is that we are not alone: CloudFoundry and Infrastructure Masons are also taking action to move the needle. And industry leaders such as Tammy Bütow and Abby Kearns are showing the way.

As former software architect Eduards Sizovs pegged it: Great developers are raised, not hired. The industry is spending tons of money and energy and trying to attract the best talent when it would often be more efficient to take juniors that can grow to their need.

“There is a new generation of developers of all races, genders, backgrounds coming up who can do these jobs,” said Max Johnson, DevOps engineer at Pypestream. “Businesses should widen their hiring scope and consider non-traditional sources that train as good, if not better, talent and coach them further for these highly skilled jobs.”

LinkedIn is among the first to understand the value of investing in people—so it’s probably not a coincidence that it’s among the best places to work in the U.S. From an internal, employee-led perspective, the company has developed a number of in-house programs for both career and technical development. For example, its Women in Tech (WIT) organization leads a number of programs to connect, inspire and grow women technologists. From an external standpoint, with its REACH engineering apprenticeship program, LinkedIn is redefining the way it identifies, recruits and trains talent. REACH is an apprenticeship program that creates opportunity for every individual with the passion and potential to either develop or restart their career in engineering. The program guides participants through various levels of technical roles at the company, with the end goal being that each individual builds their skill set and gains the experience needed to become an engineer.

“Reinventing our approach to recruiting and developing junior talent has been a great way to expand our funnel and has brought forward more diverse perspectives, forming a more robust team,” said Casey Brown, senior manager, SRE at LinkedIn and core team member of the REACH program.

As you have probably understood, SREs are a niche talent (43% of them even picked Vim as their favorite editor). But as I recently tweeted, they are ruling the world, and more of them are needed. Let’s get creative to train and hire more of these amazing professionals!

— Sylvain Kalache

April 29, 2019
Guess Who’s Coming to JFrog swampUP?

The annual DevOps gathering and JFrog user conference, swampUP 2019, is going to be here before we know it. It’s happening June 17-19 in San Francisco, providing easy access for everyone (it’s just 30 minutes away from SFO airport).

What’s swampUP? For the thriving DevOps community, swampUP is the must-attend event where developers, engineers and business leaders from top companies and industries network and share best practices for software delivery success.

While conference promotions can certainly be full of fluffy cheerleading at times, one thing I’m especially excited about is this year’s swampUP guest keynote speaker, Dr. Nicole Forsgren.

Dr. Forsgren, described as “snarky” by Forbes—a label she readily owns, if you ask—is the co-founder of DevOps Research and Assessment (DORA), which was recently acquired by Google Cloud. DORA quantified customers’ unique needs and DevOps processes to deliver custom paths to DevOps growth.

Coming to swampUP as herself—not that she could come any other way, but not as a representative of Google—to talk about her unique research and the overall landscape. She’s planning on covering many of today’s hot topics, including DevSecOps, cloud and hybrid, tooling trends and DevOps culture in a special keynote aptly titled, “DevOps: It Only Works When You Do it Right.”

If you don’t know Forsgren or haven’t seen her speak, her style and unique perspective perfectly blend data and statistics with understanding of realities that companies face. A bit about her specifically: Forsgren is co-founder, CEO and chief scientist at DORA. She is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been a professor, sysadmin and performance engineer. Her work has been published in several peer-reviewed journals. Nicole earned her PhD in management information systems from the University of Arizona, and is a research affiliate at Clemson University and Florida International University.

Once attendees get knowledge laid on them from Forsgren, there are some intriguing sessions available in the recently released full swampUP agenda around Cloud Native DevOps, Enterprise DevOps, DevSecOps and even some really cool-looking stuff around IoT. While this may be a JFrog user conference, there are some heavy hitters involved that make this a holistic DevOps gathering, including Andy Glover of Netflix, Aaron Schlesinger of Microsoft, Jayne Groll of the DevOps Institute, Carl Quinn of Zoox, Seth Vargo of Google, Jessica Deen of Azure and John Willis of Botchagalupe, among many other powerhouse speakers.

Of course, you’ll also see the expected lineup of JFrog experts, staff and visionaries swampUP attendees have come to know, including JFrog co-founder and CEO Shlomi Ben Haim, co-founder and CTO Yoav Landman, co-founder and chief data scientist Fred Simon, CPO Dror Bereznitsky, VP of business development Kit Merker and many more. There will be a few special additions this year, including former CEO of recently acquired Shippable Avi Cavale and JFrog VP of technology Ido Green.

From hands-on training to inspiring keynotes and practical technical breakout sessions, swampUp is seen by alums as a premier opportunity to learn about DevOps, DevSecOps and cloud-native delivery. There’s also a full day of training and certifications for practitioners of all levels to take advantage of!

Click here to register and join JFrog and the DevOps community at swampUP 2019.

— Jens Eckels

April 26, 2019
Different Organizations, Different DevOps Outcomes
The main motivation behind inventing DevOps platform was to help close collaboration between developers and IT operations. Basically, DevOps emerged as a great platform to bring closer together developers and beneficiaries of the app development process. DevOps initiates a cross-disciplinary practice spanning across development and operations.

The ultimate benefit of the DevOps approach is removing the barrier between development and deployment of software applications in specific business processes. Regardless, not all businesses reap the benefits of DevOps platform.

Does DevOps really suit all businesses of different sizes and niches? What are the key considerations for utilizing DevOps platform? These are the questions we will try to answer through this article.

Do All Businesses Require DevOps?

The common and widespread consensus is that any software development company geared for innovation must embrace a DevOps environment. Any business that considers innovation and smooth deployment in the software development process—a key factor in their long-term growth strategy—should take advantage of the benefits of a DevOps platform. Whenever any service provider needs to adopt new strategies to keep pace with the evolution in the software space, DevOps will come as an irreplaceable platform choice.

Despite this consensus and widely accepted perception, there are different opinions in the market. Many industry experts believe that to reap the benefit of the platform you need to have a dedicated DevOps team in place. If you have a DevOps culture and in-house DevOps team in your company, you can gain a competitive advantage.

The Key Benefits of DevOps

The main benefit of DevOps is faster delivery of software with much-improved quality. There can be several other benefits depending on the industry.

While some companies refer to the huge reduction in downtime since they adopted DevOps culture, there are still many others who simply give credit to the platform because of its integrated approach that makes the process more agile and fast-paced.

For most companies, the domino effect of getting better software at a faster speed ends up delivering sustainable growth and revenue opportunities.

Here’s a look at the role of DevOps platform across three types of businesses: small companies and startups, midsize companies and large business houses.

Small Companies and Startups

In smaller companies and startups where resources and human capital remain under-supplied, the responsibilities ascribed to developers, engineers and deployment professionals often tend to get blurred or overlap. Because of the scarcity of human resource, developers and engineers are often assigned multiple responsibilities. Naturally, in such companies, it is common to see cross-functional teams ready to engage into various development projects with ease. This makes them ideal business organizations to embrace and grow with DevOps culture.

Midsize Companies

As the companies tend to grow bigger in size and resources, they have a bigger (and often unbreachable) divide between verticals such as operations and development. In such organizations, staff are less likely to be open to cross-functional responsibilities, as many have been in the same job doing the same tasks and feel settled. This brings in a stagnant organizational process, where strong departmental divide rules the business process outcome.

This stagnant work culture makes such companies less appropriate candidates to implement DevOps environment. For these companies to reap the benefits of a DevOps platform, mass organizational changes should be brought in the team structure. Building a separate cross-functional DevOps team to handle some focus projects can also be good practice for them.

Large Companies

Large companies enjoy the luxury and abundance of resources, and this makes them much better-placed compared to other organizations. Companies such as Amazon, Facebook, Google and Microsoft have the diversity, huge experience and robust abilities to bring together cross-functional specialists from development and operations to work on ambitious projects. These organizations are known for having product-oriented units, comprising specialists from both development and operations.

Apart from their cross-functional expertise, product-focused approach and abundance of resources to roll on new projects, large companies also can make a big difference to the teamwork and motivation through a highly unified vision and strategic long-term objectives shared by every member of each team. This is why large companies always stand as suitable candidates to embrace DevOps approach and environment for their projects.

Fixing the Right DevOps Strategy: 3 Things to Consider

Beyond the organizational differences and core strengths and weakness for embracing a cross-functional DevOps approach, we must look into the key aspects that make a right strategy for any organization to incorporate DevOps into their scheme of things. Question is, despite the shortcomings and lacking, how can you embrace DevOps environment and reap the benefits? Here we provide some clues:
- Making Change a Habit. Some strategists believe that any organizational change will face a lot of friction, causing substantial harm to the immediate business outcome. But there should be no reluctance to change for this. Rather, by bringing constant changes, people get used to the friction and pain and it becomes normal. This is one way to replace traditional IT mindset with DevOps.
- Starting Small with a Neat Team. Obviously, finding the appropriate and credible skilled employee for your DevOps projects is not always easy. This is why it is advisable to create small startups or units, in which sharing the common vision and embracing a cross-functional approach becomes the order of the day. On top of that, do your best to bring out the best from your team and hire some experienced ones with knowledge of DevOps.
- Continuous Development Mindset. We all know how the DevOps platform always focuses on continuous development approach. It is easier for the software developers to embrace such approach, but for operations staff, you have to slowly make them think of infrastructure as evolving and slowly building components. That’s something challenging but not impossible.
Conclusion

DevOps has emerged as the most promising development approach for modern software developers. Though for many development companies the friction emanating from strict role divides is becoming an obstacle, the positive push by DevOps for cross-functional approach looks indomitable.

— Atman Rathod
April 26, 2019
DevOps Institute Brandjacking: When Imitation is Not the Sincerest Form of Flattery
“There can be only one” ~ Duncan McCloud, Highlander

They say that imitation is the sincerest form of flattery. Often it is absolutely true. But stealing, ripping off and/or trying to trade on the name of others crosses the line between right and wrong, legal and illegal. As a co-founder of the true, one and only DevOps Institute, I was appalled to see the efforts of another company, whose name I won’t even dignify in this article, trying to launch “the DevOps Institute.”

If you told me that this company perhaps did not know that there was already a DevOps Institute (it’s not like we hide it), I would say OK, maybe it was an honest mistake. But no. In this case, the company in question actually reached out to DevOps Institute—us—and had several conversations/interactions regarding becoming a registered education partner of the DOI. What the company reps were actually doing was fishing for information as they sought to launch their own version of DevOps Institute. So this is certainly not a case of an innocent mistake; rather, it’s a deliberate attempt to misappropriate the name, assets and hard work of another. Where I come from, the streets of NYC, we call it stealing.

You have to ask yourself: Knowing what we know of the situation, why would these people commit such an unethical, illegal act? I can only come up with a few reasons:
1. They are seeking to deceive and confuse the public by literally trading on DevOps Institute’s—our—good name to make a quick buck.
2. They are part of those in the world who do not respect intellectual property, seeking to sell out the back door anything they get their hands on from the front door.
3. They are unscrupulous thieves who are incapable of building a business by themselves.
No matter whether one or all of the above, none of the reasons are very good.

In generally acceptable business practices worldwide, there are more than several acceptable ways for companies to imitate the business strategy and models of others. More power to them—after all, competition makes us all up our game.

In the DevOps education training and education space, there is certainly no shortage of competitors. Just do a Google search of DevOps Institute and look at the companies buying that ad word or otherwise using SEO to get listed. Lots of competitors, for sure. Remember, this isn’t even a generic “DevOps training” search, but actually searching for DevOps Institute.

Taking another’s name crosses the acceptable boundary. So now we have to lawyer up to protect our rights and property. No one likes to throw good money at lawyers to go after bad actors. But protecting one’s brand, reputation and IP is that important.

For those of you familiar with the DevOps Institute, you know that the team has worked hard for more than four years now to lead the way in curating content for bringing DevOps training, education and certification to the market. It hasn’t always been smooth sailing. When DevOps Institute launched, we faced strong headwinds from those who thought a training/certification program around DevOps was wrong. We listened, we learned, we set up the feedback loops and we iterated (like good DevOps should). We have won over many of our critics; they saw the good work we were doing.

More than that, they saw DevOps Institute try to be stewards of and active participants in the DevOps community. We are not in this for the fast buck or the quick hustle. The executive team has plowed our revenue back into the company and community, expanding the association’s offerings and reaching out to DevOps communities throughout the world. Today, DevOps Institute has ambassadors in Europe, South America, AsiaPac and of course here in North America. We go wherever DevOps goes.

Recently DevOps Institute has tried to build a greater DevOps community based on the Humans of DevOps and our SKILS framework (Skills, Knowledge Ideas and Learning). We have worked with the leading names in the DevOps industry to do research and help bring greater understanding of DevOps. We have sponsored and spoken at many of the DevOps events you have attended. In fact, I am satisfied to rest on our laurels.

If you are not familiar with the real DevOps Institute (and that is at https://devopsinstitute.com, btw) check it out for yourself. We have nearly 200 partners around the world who deliver training for our certifications. We have a healthy global community and active engagement with industry thought leaders. We obviously are doing something right.

Finally, I wanted to speak to my entrepreneur friends in the audience: Those of you know who know me, know that this isn’t my first rodeo. I have founded and helped several venture-backed startups through IPO and exit. I have had my share of wins and my share of losses. I am not one to whine or back down from some good competition, but this kind of shadiness has no place in the business world.

We put a good chunk of our own blood, sweat and tears into our businesses, and for someone to swoop in and steal the fruits of our labor is just plain wrong. Brandjacking is stealing. I started this article off with the quote from “Highlander.” So if you see me walking around with a severed head or sword in my hand, remember: There can be only one.

— Alan Shimel
April 25, 2019
How to Improve DevOps Visibility
DevOps, by design, works quickly and accomplishes deadline-driven projects rapidly. With a high amount of project turnover, visibility into key operational data is easy to mismanage and can lead to simple mistakes, lack of optimization and organizational misalignment. To examine the effect of DevOps visibility, SmartDraw commissioned the “2019 DevOps Visibility Report.” The results were decisive: Each company surveyed is seeking ways to better DevOps visibility, and 84% of respondents list it as somewhat to extremely important to their organization. But achieving DevOps visibility is not always simple.

Roadblocks to Achieving DevOps Visibility

Respondents identified that visibility reports take skilled workers away from their other priorities. In a small, fast-moving lean team, removing a skilled worker from a key deadline-driven task can cause performance and timeliness to suffer.

Further, the reports often are visually complex and not useful. If the team member creating the visualization is unable to design it in a simple fashion, the report is often wasted effort as it provides no actionable insights.

Finally, and potentially the most harmful, the reports are static and do not accurately represent the current state of information. DevOps teams are meant to be agile, and poor report updating practices can lead to stale data. When that stale data is used to make decisions, organizations lose productivity and quality.

So, what should DevOps managers do to improve this process?

Key DevOps Visualization Recommendations

The “2019 DevOps Visibility Report” uncovered four insights to improve operational visibility and efficiency with expanded real-time DevOps data visualization:
- Avoid building static reports in spreadsheets: Spreadsheets, while effective at data analysis, are not the correct medium for visibility reports. The static data quickly become out of date and useless. In today’s modern business landscape of rapid change and competition, any manual work becomes a risk to an organization’s decision-making ability.
- Present common DevOps information in an easily comprehensible manner: Respondents reported challenges in reporting data in a way that a variety of audiences could comprehend. These reports are designed to be consumed by multiple levels of the organization, with varying degrees of technical knowledge. The most successful respondents focused on visualizing data in an easy-to-understand way.
- Adopt low or no-code solution for visualizing unique relational data: By utilizing a solution that is fully or mostly automated, organizations allow their skilled team members to prioritize deadline-driven work. Further, this automation allows for improving real-time information and lessens the likelihood of stakeholders making decisions based on old, outdated data.
- Create self-service reports that enable non-engineers to visualize DevOps data without submitting change requests to engineering: It’s crucial to be able to remove DevOps team members from the update process. Key stakeholders should have the ability to generate a report easily and without input from DevOps. Additionally, this report should be based on existing source data, and should allow for anyone to drill further in to see the raw numbers that the visualization is drawn from.
Conclusion

A good DevOps process improves quality, lowers cost and saves time. Yet, poor visibility can limit DevOps success and lead to misalignment. Organizations should adopt an automated real-time DevOps visibility solution to allow team members to focus on the crucial pieces of their role, provide relevant information to managers and create digestible visualizations.

— Joshua Platt
April 24, 2019