devopsy.kinsta.cloud

Category: Enterprise DevOps

SRE Is the Most Innovative Approach to ITSM Since ITIL

For over a decade, ITIL has been the leading ITSM framework adopted by enterprises across the globe. So, what is driving a rapidly increasing interest in Site Reliability Engineering (SRE) as a service management alternative?

In its own words, Google refers to SRE as its approach to service management: “The SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response and capacity planning.”

In traditional ITSM terms, the role of the SRE is responsible for service level, change, availability, event, incident, problem, capacity, performance, infrastructure and platform management. While the operational practice areas may be similar, there are significant differences in how the practices are approached.

ITIL4 Framework Compared to SRE

Released in 2019, the newest update to ITIL4 remains a complex governance model with four dimensions, seven guiding principles, a Service Value System and 34 processes (now renamed as practices). While ITIL4 pays homage to Agile and DevOps, there is little depth in the publications released to date—to be fair, several other publications in the series are in queue for gradual release. The framework spans just about every aspect of software delivery and operations and seemingly is trying to be the single source of truth in both principle and practice for IT management.

SRE Is More Closely Aligned to Agile and DevOps

By comparison, SRE focuses specifically on the reliability and resilience of complex production system operations. As an engineering discipline, SRE more closely aligns with the Agile and DevOps patterns that are being adopted by product development teams including continuous integration, testing, delivery and deployment. SREs bring the wisdom of production into the teams thereby breaking down many of the silo walls that have impeded IT for so long.

As a service management alternative, SRE also updates traditional ITSM activities with innovative and self-organizing concepts such as management to service level objectives, error budgets, toil reduction, release engineering, monitoring/observability and embracing risk as neutral approaches to service management. The core SRE book provides practical and actionable guidance for Site Reliability Engineers on managing incidents, learning from failure, testing for reliability, load balancing, handling different types of emergencies, software engineering and capacity planning. Related publications such as the Site Reliability Engineering Workbook and Seeking SRE provide additional insight.

Most importantly, a Site Reliability Engineer is an actual hireable job with a defined role, set of responsibilities and skills. SREs and SRE teams are encouraged to be creative, accountable and must spend 50% of their time reducing toil by engineering automation in order to make tomorrow better than today. Like Agile and DevOps, SRE supports self-regulation with policies and consequences. In fact, some consider SRE to be the third piece of the Develop (Agile), Deploy (DevOps), Operate (SRE) feedback loop.

What This Means for the “Humans of DevOps” in Operations and ITSM

SRE is breathing new life and opening new career paths for operations and ITSM professionals who a few years ago were battling against the mantra of “NoOps.” According to Linkedin’s 2020 Emerging Jobs Report, SRE is the fifth fastest-growing job role with 34% growth.

Services will always need to be managed. However, competing in a digital age requires new ways of working and thinking with speed and quality as key metrics. Agility must be instilled across the value stream spectrum in order to increase flow and deliver an exemplary customer experience. Your organization may not be as complex as Google’s, but the principles and practices of SRE are applicable to all environments.

You can read the Site Reliability Engineering and Site Reliability Engineering Workbook publications for free from Google. For those wanting to learn more about the practices and patterns associated with SRE, DevOps Institute recently released its Site Reliability Foundation certification with accredited training being offered globally by its Global Registered Education Partner network. Either way, if you are an operations or ITSM professional, I would highly recommend learning more about SRE. It is the future of ITSM as we cross the digital divide.

— Jayne Groll

January 31, 2020
Three Ways You Can Embrace Curiosity to Climb the Career Ladder

As the product manager of a high-growth startup, my role has evolved quickly over the past four years. When we started the company, in a garage along one of the many Amsterdam canals, I found myself doing everything from writing code to taking out the trash and ordering dinner for the late nights in the office. Since then, our team has grown rapidly and we are now in a beautiful office where we are proud to host global brands—something we didn’t do in the garage.

When I joined MessageBird, it was a small company so we each wore many hats and shared responsibilities. Regardless of the hat we wore at any given time, each person stepped up and took the opportunity to learn new skills to help the company reach the next level of success. As the company has grown, I’ve grown along with it. I started as a developer and now, four years later, I am managing product development for our platform of communications solutions.

As I think back to how I got here, there were three key practices that paved the way. In addition to never saying no to a job—even if it wasn’t in my job description—I’ve found that nurturing these three practices can go a long way to building a career.

Ask the Long-Term Questions Early and Often

When asked to select from a list of 34 attributes that represent their top strengths, 76% of product managers chose “always learning,” and 64% selected “curiosity.” When coupled with a long-term focus, a learner’s attitude is a strong asset for personal growth. At a startup, prioritization of efforts at any time can mean the difference between success and failure. Part of my success was born from simply asking why. Why are we building this now? What customer pain are we solving? Why this focus over that one? Asking why early and often forces a team to slow down and think through whether they are focusing on the right outcomes. And, it’s helped me prioritize my time to have the most impact.

Be a Dreamer, but a Critical One

Whether working as a developer or as a product lead, rallying the team around our mission and potential is critical to success. One of the most effective ways to do this is to dream big—and encourage the team to do the same. Imagining what could be is not only fun, but it helps us aim high. While we dream big, we remain critical of our ideas and open to the input and criticism of others. As we take in new input and ideas, we adjust our thinking but remain persistent on the end goal. To make an impact in a growing company, it’s important to keep one foot planted in solving current customer challenges. But, that doesn’t mean you shouldn’t keep an eye on the future and dream big.

Acknowledge that You Don’t Know What You Don’t Know

Growth and leadership are recognizing when you don’t have all the answers and having the confidence to admit it. I’ve learned that the best ideas don’t typically come from one brilliant mind, but rather from the collaboration of several minds. MessageBird was founded in the Netherlands which is a very small country. In fact, two hours in any direction and you’re in a different country with a different language and a different culture. As such, we’re fortunate to have over 30 nationalities represented. Naturally, different backgrounds bring different perspectives and different sets of knowledge. It’s a culture that has given us an edge because the diversity of thought enables us to see challenges from very different viewpoints.

I’ve come to learn that not knowing something is OK as long as you stick to the pursuit of knowledge and validation. You will make some mistakes along the way, but don’t get stuck on what you don’t know. Let not knowing drive you to learn.

Embracing curiosity, dreaming big and working together toward solutions are the best ways I’ve found to solve customer challenges and move your career forward at the same time. Hopefully, these tips help you drive yours forward, too.

— Joey van Ommen

January 28, 2020
Pendulums and DevOps

I have long noted the trend of pendulums in IT, particularly in organizations with longer histories. Centralized IT will be achieved, its weaknesses noticed and a movement will begin to decentralize. Decentralized IT is achieved, and people remember its weaknesses, causing centralization.

The same is true with speed of delivery versus quality. Faster will be more important for a while, then the reality that faster causes quality concerns will surface, and reliable becomes the keyword, causing slower rollouts of better product.

This has been going on since I started in IT, and while it is more evident in enterprises, any company that lasts long enough will see these cycles run through.

Agile and DevOps, as the Great Disruptors, stood a chance of redefining the tensions that cause these pendulum swings. Centralized versus decentralized is less important if stakeholders are all truly involved and informed—something that the culture side of the DevOps crowd aimed to achieve. Similarly, fast and quality were promised, as the ability to recover from inevitable mistakes would be rapid, while integrated testing would uncover most issues.

We have enough years under our belts to know at this point that these issues are, at best, resolved with a resounding asterisk that is clarified sometimes.

One nice thing about DevOps (more than agile) is that it has not stopped evolving yet, which means there is still hope that rapid delivery and high quality can both be answered while involvement of business owners and all the various IT groups will reduce the centralized/de-centralized cycle. But we’re not there yet.

Split.io—purveyor of feature flagging/tagging tools—has a pretty good blog about what they discovered when they went out and talked to hundreds of shops. It shows that failures are happening at an alarming rate, and at some number of shops, for your average bug, they will still be fixing this released issue when the next release goes out. That is asking for trouble, in my experience.

Better integrated testing is certainly part of the answer. TDD is good, but not enough, since it is more granular than some tests require. Split believes that feature flags are part of the answer, and I believe they’re right. But this approach is a band-aid to the problem.

By the time you flip a feature flag to turn off a bad feature, you’ve already released a bad feature. And you will be spending time researching and fixing it. I believe feature flags should be used to catch it when this (inevitably) happens in a complex coding environment, but at the same time the source of issues should be looked into. An ounce of prevention is indeed worth a pound of cure.

Figuring out what is allowing bugs to slip through into production rather than counting on remediating them (using precious time to do re-work) should be a priority moving forward. Is there a process/policy that is at the source? Is it simply a training issue? Training issues are repetitive—teaching today does nothing for new algorithms/tools put to use after today, and turnover can create a training gap if you’re not staying on top of it. For some shops, is speed of delivery faster than some piece (normally testing, but some shops suffer for development on certain platforms also) of the delivery chain can adequately respond to? Do you need to re-evaluate toolchain and delivery timelines?

We are delivering more code, faster than ever, and that is exciting. But quality matters, and anyone who relies on end-users to test is playing a very dangerous game. Find ways to ensure quality without slowing down the process more than necessary. At this point, I honestly would implement runtime-flippable feature flags as a starting point, simply to be more responsive to issues. From there, work to resolve the underlying reasons that bugs are cropping up.

Until then, keep cranking it. Keep working with the business to get quality systems in front of users, and enjoy doing some great work.

— Don Macvittie

January 27, 2020
Five Technology Trends to Shape Future Investments

Humans invented technology to introduce innovative products in the market. Technology’s relentless cycle of innovation has now touched humanity, redefining what it means to be a human, a meaningful change that is impacting business priorities and is expected to do so in the future.

The most important tech investment for C-level executives relates to digital transformation, artificial intelligence (AI), Internet of Things (IoT) and cybersecurity. With 71% of the world expected to use mobile phones by 2024 and the successes of mobile banking in developing countries, experts predict that mobile and blockchain technologies will also join to bring about more financial inclusions.

Here are five things that C-suite business people should invest in.

Digital Transformation: Everything Online

As one of the weapons in the arsenal of business innovation, digital transformation has become such a buzz word that it turns people on. According to a report by Forrester, 90% of the executives believe digital transformation is a necessity for their business, and around 60% believe they lag behind in digital transformation. By the end of 2020, a company would either have transformed or will be on its way to adapt to digital transformation.

IoT: A Thousand Points of Entry?

Business implementation of IoT and blockchain are very popular these days. However, if we look to enterprises it’s a different story. Costs, security and current political climate are the major hurdles for the enterprise-level implementation of IoT. To get the most out of this innovative technology, businesses need to determine what stands in their way and then work on strategies to sort things out. So until the issues are dealt with, IoT will be seen as a promising technology that’s not ready for prime time.

AI: A Real Game-Changer

Every so often a technology comes along that has the potential to completely change everything around it. The last such thing was cloud computing. Like cloud computing, AI has been around for a long time. AI, machine learning and deep learning are catching up with the initial promises and it will become more evident in the coming years.

Most common usage of AI and machine learning will be seen in business intelligence, automating the repeated tasks, and making future prediction using the previous data. Previously, AI has been used for decision making using data analytics and this is expected to increase in the coming years with more businesses investing in the AI-driven decision-making system. Another use of AI that will be more common is digital identity verification for online businesses.

Ultimately, AI/machine learning and deep learning will be seen more frequently in the years ahead. However, the promises it brings are far fetched and it’s worth waiting to see the true potential of AI.

Quantum Computing: The Next Big Thing

Currently, in R&D, quantum computing will open new ways by solving problems that require a lot of computation. Google’s investment in quantum R&D is expected to grow and more researchers will shift their focus from AI to quantum. With the emergence of 5G, the quantum research industry will see a boom.

DevOps: For a Customer-Centric Approach

According to the Forrester report, firms will embrace a customer-centric approach as the DevOps speeds flatter. DevOps continues to impress the heart and minds. However, with a slow-release speed, engineers are experiencing a stress point. DevOps teams must see this as an opportunity to approach DevOps differently. Within the next six to 12 months, DevOps adoption will change and the team will implement new strategies. Testing will revolve around previous radical methods and new technology will help developers to learn new skills.

— James Efron

January 24, 2020
These Three Approaches Will Help Your Enterprise Be More Agile

Nearly every organization that tries to change its culture to be more agile and better adapt to changing environments discovers that it’s harder than it looks. Agile transformation can’t be superficial or only embraced by the IT department–it needs to be completely pervasive throughout the business.

There is no one-size-fits-all approach or playbook that can be used to fit any organization’s unique situation. Yet, there are some common takeaways and best practices that can be gleaned from organizations that have successfully undergone agile transformation. Here are three common themes I’ve come away with from talking with organizations at various stages of their agile journey.

Creating an Agile Enterprise Relies on Successfully Orchestrating Change in Culture, Organizational Structure and Technical Capabilities at the Same Time

Changing enterprise organizational structure without changing culture and technology will lead to factors that drag down any potential transformation. It’s equally true when addressing any one of the elements in a vacuum. Instead, enterprises must address all three at once, which makes for a tricky prioritization exercise.

In many cases, new solutions will lead to new problems that organizations must address as they arise. Agile teams enabled to self-organize and pursue customer problems with greater freedom may find themselves hamstrung by inflexible legacy technology. Changing technology to enable agility may uncover additional organizational difficulties, and so on. Agile transformation is a long journey, and enterprises must adjust on the fly to their own unique circumstances.

When Making Changes to Drive Agility, Think About What Scarf Everyone Wears

Missy Lawrence-Johnston, a principal consultant from ISG’s Organizational Change Management practice, suggests that leaders should remember a warm and fuzzy acronym when working toward change: status, certainty, autonomy, relatedness and fairness (SCARF). The SCARF model was developed by neuroscientist David Rock, and explains how individuals react to change based on perceived threats and rewards.

If a change negatively impacts someone on one of the dimensions they consider important, they’re more likely to push back on it. For example, a manager who cares a great deal about their status will probably have difficulty embracing an organizational shift that works to cut down on organizational hierarchy. But that same change could be highly valued by a rank-and-file employee who prefers greater autonomy. How people react is individual, which is why the SCARF everyone wears is unique to them, as Lawrence-Johnston points out.

As enterprises make the changes necessary to embrace agility, keeping this concept in mind will make it easier to navigate the threat responses employees inevitably have.

Measure Culture by the Behaviors People Exhibit at Work Every Day

ISG research shows that culture and team enablement are the most important factors when transforming into an agile enterprise. While culture can seem like something nebulous and difficult to pin down, it’s best evaluated by noticing what people do every day. Odds are, any employee of a firm has at least one story that illustrates what they see as the culture of the organization where they work. An enterprise’s culture is the sum of these stories.

Agile transformation requires some fairly radical changes for businesses that are used to working in a waterfall mindset. This often looks like a shift from a hierarchical, rule-driven culture that focuses on command and control to a collaborative, self-organizing culture with servant leadership. Implementing this degree of change takes significant work.

When changing culture, it’s not enough to put up a fresh set of posters with new values. Living those values and building organizational structures to support them is the key to success.

— Blair Hanley Frank

January 22, 2020
Edge Computing and ITOps: Opportunities and Challenges

Edge computing is growing quickly, but IT operations need to evolve as well to effectively monitor and manage new devices, sensors, applications and data. Growing enterprise edge ecosystems should integrate and become part of centrally managed ITOM systems.

Edge computing is hard to define and is running high on the hype scale. But, research and surveys continue to indicate that this trend of processing data where it’s collected for better latency, cost savings and real-time analysis is an innovation with legs.

There will be 75 billion IoT devices by 2025, according to Statista. According to Spiceworks’ 2019 State of IT report, 32% of large enterprises with more than 5,000 employees are using edge computing, and an additional 33% plan to adopt it by 2020. Tied to the growth of edge computing is the advent of 5G wireless: 51 operators globally will start 5G services by 2020, according to Deloitte Global research from 2019.

The major cloud companies are also investing in the edge. The AWS Local Zones service allows single-digit latency connecting to computing resources in a metro environment, while Microsoft offers the Azure Stack Edge appliance and Google Cloud IoT is a “complete set of tools to connect, process, store and analyze data both at the edge and in the cloud.”

It’s safe to say that edge computing is becoming mainstream, and CIOs and their ITOps leaders should plan appropriately for it in 2020 and beyond.

Benefits of the Edge for ITOps

We’ve read plenty about the business benefits from edge computing: oil rig operators need to see critical sensor data immediately to prevent a disaster, marketers want to push instant coupons to shoppers while in the store, video security monitoring can catch a thief in the act and medical device alerts that ensure patient safety. Edge computing may save IT money on cloud and network bandwidth costs as data volumes keep exploding and the need to store every data point becomes harder to justify.

There are also implications for IT management and operations. Local processing of high volume data could provide faster insights to manage local devices and maintain high-quality business services when seconds make a difference—such as in the event of a critical server performance issue threatening the e-commerce site.

Today, ITOps teams are inundated with data from thousands of on-premise and cloud infrastructure components and an increasingly distributed device footprint. The truth is, only an estimated 1% of monitoring data is useful, meaning that it provides indications of behavior anomaly or predictions about forthcoming change events. With edge monitoring, we can potentially program edge-based systems to process and send only that small sliver of actionable data to the central IT operations management system (ITOM), rather than transmitting terabytes of irrelevant data daily to the cloud or an on-premise server where it consumes storage and compute power.

The job of filtering out the highly-contextual data on the edge, where business occurs, can support real-time decisions for successfully running ITOps at speed and scale—regardless of what combination of on-premise, public cloud or private cloud infrastructure is in place. At the same time, ITOps will need to be a leader when it comes to minimizing the risk of edge technology from a performance, security and privacy perspective. However, as detailed below, we are in the early stages of determining how to make this work in practice.

ITOps Realities for Edge Computing

Edge-Specific Security Needs Are Still Unknown: Edge devices are often small and infrequently designed with security in mind. More than 70% of edge devices don’t mandate authentication for third-party APIs, and more than 60% don’t encrypt data natively. So the attack surface in IoT and edge environments is now larger, and less secure. This is particularly worrisome when considering edge devices that collect personally identifiable information such as email, phone numbers, health data or financial formation such as credit card data. ITOps will need to work closely with security and legal teams to map out the company-specific risk, governance and compliance requirements around managing edge data.

Edge Monitoring Tools Are Immature: Companies need platforms that can instantly monitor and analyze edge-generated data. In the connectivity of tomorrow, billions of connected devices will be communicating machine-to-machine, and the addition or subtraction of connected devices will be possible at an unprecedented scale. In this environment, the ability to manage large volumes of connected devices and the information being exchanged between them will be critical. 5G acts as the unifying technology, bringing flow of information and the density of scale. We will see an influx of innovation in edge monitoring in the coming years.

New Environments Call for New Rules: As organizations move more data and application assets to edge computing environments, IT will need to devise new policies and thresholds for central processing and alerting of all this data. Applying AI-based automation is essential here, as manual efforts will have zero chance of keeping up with the volume of data filtering, analysis and response. We are entering the age of nano satellites, vis-à-vis SpaceX and OneWeb. These edge devices will transform the future of agriculture, energy, mining, transportation and finance due to their capabilities for sending insightful data in real-time to customers, wherever they are at any moment. ITOps will have its work cut out to understand and properly manage this evolving edge infrastructure.

DevOps Processes Will Become Even More Paramount: If you haven’t already realized that DevOps is taking over software development and IT management, just wait for when edge goes mainstream. There will be no other way to manage change and deployments of edge technology without the agile, continuous integration and continuous delivery methodology of DevOps. It will be imperative for ITOps to adopt DevOps practices and tools to manage, monitor and deploy edge resources.

ITOps is at a crossroads, determining how much of the past is still relative and how much they will need to change to adapt to a distributed, hybrid cloud world that will soon include edge as a fundamental pillar of their digital strategy. Security, machine intelligence and DevOps will be crucial areas of expertise for ITOps teams looking to help drive better business value and customer experiences from the edge.

— Bhanu Singh

January 22, 2020
Red Hat Extends Runtimes Middleware Portfolio

Red Hat has made available the latest instance of Red Hat Runtimes, a suite of lightweight open source components and frameworks that makes it easier to discover the middleware most appropriate for building a specific type of application.

James Falkner, product marketing director for Runtimes at Red Hat, said as organizations embrace cloud-native application architectures based on microservices it’s become increasingly challenging to determine what middleware to deploy optimally and where. Red Hat Runtimes not only makes it easier to navigate all those options, Falkner said, but all the components and frameworks are certified to be pre-integrated.

The latest version of Red Hat Runtimes adds support for Open Liberty, a lightweight runtime for building Java applications developed by IBM. Red Hat was acquired last year by IBM.

The latest installment of Red Hat Runtimes also provides access to what has become a standard distribution of Node.js based on Red Hat Software Collections that will be implemented across all Red Hat offerings.

Finally, Red Hat has also added support for Red Hat Single Sign-On, an access control framework based on the Keycloak project.

Falkner said Red Hat Runtimes also serves to reduce the total cost by providing a single subscription through which organizations can access everything from container runtimes to the 3Scale application programming interface (API) management middleware, which Red Hat acquired in 2016.

Very few IT organizations these days are standardized on a single class of middleware, especially as they embrace microservices-based applications built using containers. Most IT teams for the foreseeable future will need a flexible way to access multiple runtimes in support of everything from monolithic applications based on Java to applications built using Node.js code deployed using Docker containers.

Rather than a piecemeal approach to the middleware infrastructure required to build, deploy and integrate all those applications, Falkner said Red Hat Runtimes provides a more holistic approach.

It’s not clear how much or even whether IT organizations are centrally managing middleware in the age of DevOps and the cloud. Historically, many IT organizations preferred to standardize on a single application server platform to deploy various classes of middleware. However, many developers today are deciding what middleware to include within their application stacks without much input from a central IT function.

Via Red Hat Runtimes, Red Hat is trying to make a case for providing developers with the flexibility they cherish in the form of a subscription service that provides IT teams with a modicum of control over what middleware gets employed.

Tensions between DevOps teams and central IT organizations have arguably never been higher. In fact, many DevOps teams are operating within lines of business that are outside the direct control of centralized IT. As such, the level of standardization that can be imposed by central IT organizations has become more constrained. Many centralized IT organizations are now trying to influence middleware platform decisions rather than outright make decrees that might get ignored anyway.

Regardless of the middleware platform choice that ultimately gets made, however, the one thing that most centralized IT teams will have to come to terms with is finding a way to support it.

— Mike Vizard

January 21, 2020
The Difference Between Capacity and Scalability Planning

Not only does the tech industry love terms, we love to make them super nuanced. For example SecOps versus DevSecOps, continuous delivery versus continuous deployment, hybrid cloud versus multi-cloud, etc. These terms may seem similar on the surface, but when you dig in they are quite different.

Here are two more: capacity planning versus scalability planning. Both are critical aspects of keeping applications up and running, but two different activities.

The reason we invest time in capacity and scalability planning is simple: We want to make sure that system resources such as compute, storage and memory are not the cause of an application outage. It is a response to expected and unexpected increases in application usage, as well as the steady growth of application adoption.

Here are a few differences between capacity planning and scalability planning.

Long Term Versus Short Term

Capacity planning is more focused on the base resources, as it relates to the long-term growth in application traffic. The goal is to have enough resources to handle the steady state of the application without breaking the bank by over anticipating usage. With capacity planning there is a big assumption that the application requires to always have a pool of resources available.

Automated Versus Static

Scalability could be a manual task, you see utilization creeping up and you respond with more instances. This is probably more common than not. But I don’t believe it’s the overall objective of most teams. Auto-scaling is the goal, where the system knows on its own when it’s time to spin up new resources. The public cloud providers, instrumentation of kubernetes, etc., help support this. Whereas capacity planning is a more deliberate identification of needs, and then statically setting those resource needs within the cloud.

Strategic Versus Responsive

Similar to static versus automated, capacity planning is a more strategic activity whereas scalability planning is a more responsive activity. Usually, scalability comes up during peak usage activities such as black Friday sales or school registrations.

Capacity planning generally calls for more research and leveraging tools such as load balancers and historic data to understand the best path forward. It also should involve the input from the broader team, especially development to discuss the resource usage of new functionality and application architectures.

There is a good possibility that scalability planning could be all that is left with some modern applications. The reason this might be true is resource allocation theoretically can be 100% application based, where the resources are always one step ahead of current utilization. In order to embrace this model resources need to be provisioned 100% automatic, which means that all infrastructure needs to be scripted. As more companies adopt serverless components of their application, this is already inherently true.

Capacity planning is where most operations teams spend their time, but resource utilization is shifting left and scalability planning is becoming more common. Scalability planning has become the responsibility of DevOps engineers, SREs and even developers. The main reason capacity planning will survive the long haul relates to budgets. While the application itself can fully control the infrastructure laid out before it, the IT organization and the organization itself will want to impose an upper limit so there is an indicator of when the cost of running the application on the resources may or may not be an issue. Capacity planning in this case will be purely a cost control mechanism, and negotiated just as any budgets are.

— Chris Riley

January 17, 2020
How to Use DevOps for Compliance

Picture this: You’ve been working in an organization’s IT department for a couple of years and tasks have become quite a routine. Some documentation here and there, code reviews, end-user training, routine meetings with the developers and so on. You can do literally everything with your eyes closed.

Then, all of a sudden, the company is going public and you feel like you’ve been thrown into a different dimension. There are new procedures to follow, endless meetings to attend and a ton of paperwork to be shipped. And don’t forget the new compliance regulations.

When this happens, do you gamble and quit or stick around and accept the new reality? Is there a truly viable option?

In comes DevOps.

DevOps means different things to different companies. Some IT experts consider it a fad while others swear of its significance.

In many organizations, DevOps combines development and operations. With it comes automation, efficiency and more transparency. With DevOps, changes can be rolled out much quicker.

DevOps can be the silver bullet for organizations looking to keep up with HIPAA, GDPR, PCI SOX and other industry regulations.

Here are four strategies for using DevOps for compliance.

Keep Track of Documentation

A big part of compliance involves documentation. Yes, boring but critical. With a unified development and operations team, you can merge the documentation processes of those who release changes and those who make them. It’s also easier to get everyone on board when it comes to compliance requirements.

You can use the newfound synergy between dev and ops to avoid documentation bottlenecks by adopting a unified and trackable version control system. Tools such as Git, wiki pages and internal dashboards can be used to harmonize documentation and version control.

Make sure everyone is on board by conducting routine training and holding meetings involving both dev and ops personnel.

Leverage DevOps Automation

Part of the reason why DevOps has attracted so much attention is the automation it brings.

With DevOps, time-consuming tasks such as monitoring pull requests, internal audits, access controls, code reviews, failovers and code coverage can be optimized through a transparent, unified and automated system. For instance, you can link all deployments, code review and build results in a single process to streamline audits and daily operations.

DevOps automation not only helps to streamline internal processes but also in demonstrating that you have met all compliance requirements. Things like access control and failover/recovery processes can stifle your compliance efforts if they are not optimized through automation.

Streamlining Dev Workflows for Compliance

Most compliance problems stem from messy development workflows that are not helpful for those keeping track of updates. For instance, an update that is put into production without going through the normal stress tests or internal reviews is not helpful. With multiple teams working on different features during the development stage, it’s easy to overlook small updates that could potentially introduce vulnerabilities.

DevOps helps to prevent accidental compliance breaches emanating from flawed dev workflows. This is achieved through the integration of stress testing into the development process itself.

With DevOps, you don’t have to wait until an update is ready for production to stress test it. Working with a dedicated compliance team, you can create a compliance blueprint in the form of a testing and logging system to keep track of code that is still in the production stage way before it goes into production.

Foster a Compliance Culture

In a non-DevOps environment, it’s common for different teams or individuals to blame each other, refuse to take responsibility or be out of touch with processes that are not in their job description or assignment. To ensure compliance, a bit of team management is required through communication and culture development.

DevOps makes this process easier thanks to the improved inter-team dynamics, automated processes and increased transparency. It’s easier to merge the dev and ops teams to help identify potential trouble spots and ways of resolving them. The operations staff will not blame the developers when a disaster occurs if they were part of the entire process and vice versa.

Effective teams always take responsibility instead of looking for a fall guy or starting finger-pointing when something is amiss. Inculcate a culture of compliance in your teams by ensuring that they are all aware of what is required of them and their shared responsibilities.

From the above, it is clear that DevOps can be the only thing you need to ensure compliance in your organization. However, adopting multiple recommendations at a go can be challenging. Therefore, take it one step at a time and use available tools, such as Git, to implement some of these processes.

— Ken Lynch

January 15, 2020
Why Is QA so Important in Executing a DevOps Implementation Strategy?

In a rapidly growing global digital landscape, enterprises are facing many challenges. These include changing customer behavior and the need to be in line with the latest technology trends. To address these challenges and to stay up the competition curve, enterprises are adopting a slew of strategies. These comprise expanding the capacity of processes, quick quality checking and delivery of applications and timely marketing of the applications. This is where DevOps comes as a one-stop solution to the aforementioned requirements.

When it comes to assuring the quality of software applications, the Agile and DevOps model of testing is favored over the traditional waterfall model. This is because software applications need to be tested across a swathe of platforms—devices, browsers and operating systems. In the DevOps scheme of things, software builds are continuously integrated and deployed in the development pipeline by using test automation. It involves the development and implementation of new features along with the streamlining of processes.

What Is DevOps?

DevOps is an amalgamation of terms “development” and “operations” and is underpinned on four basic pillars—culture, tools, collaboration and practices. Combining processes and philosophies, the DevOps approach helps enterprises deliver quality builds in the SDLC. Here, development and operations teams no longer work in silos but in close coordination with each other. As a result, quality becomes a shared responsibility and a culture of accountability gains ground. DevOps implementation leads to the quick development and deployment of quality builds, faster solving of critical issues and engendering greater trust and confidence.

Let us understand the best DevOps implementation strategies to derive outcomes such as continuous integration (CI) and continuous delivery (CD). To begin with, getting the QA basics right the first time and every time should be considered as part of the strategy. This is due to the fact that in a pure DevOps ecosystem, the lines between development and QA are blurred.

Test Automation

Since the software needs to have an omnichannel interface with third-party applications to perform optimally, the test process should be automated. There should be a smooth QA-DevOps alignment to detect and mitigate glitches early on in the SDLC. Thus, DevOps testing may involve choosing automated tools that are either open-source or commercial.

Teams Merge

To derive DevOps transformation, the integration of the QA team with other technical specialists becomes important. The final DevOps team should adapt a culture wherein identifying glitches becomes a shared responsibility.

Metrics

Since DevOps testing is all about quick identification and fixing of glitches, the metrics should be defined at the beginning. It will help the DevOps team to stay focused on the challenges and requirements. This calls for the QA engineers to setup test requirements into the workflow and guide the team therein.

Virtualization

The software application should be tested across a slew of platforms—devices, browsers or operating systems. Since it is well-nigh impossible to test the codes for numerous users (during usability testing), the same ought to be created virtually. The QA team can virtualize every test requirement to emulate the behavior of software components. Moreover, it helps to do away with the need for dependencies and addresses constraints faced in interdependent environments.

Choose the Right Tools

To enable DevOps automation, the QA team should choose the right test automation tool. The main criteria for choosing the tool should be the team’s expertise in using it. The tool should offer the ease of writing the test script in a single programming language. It should allow the testing of applications across operating platforms and browsers.

Continuous Integration and Continuous Deployment

These are the outcomes of any DevOps methodology. DevOps continuous integration and deployment encompass adding code changes in a repository and creating automated builds. This leads to an early recovery from failures as well as testing and delivery of products within fast turnarounds. Continuous integration based on test automation leverages regression testing and a version control system when a new code is added. Further, DevOps continuous deployment is about the capability to add new features to the existing applications. This makes enterprises follow a user-driven improvement of software and agile approach.

Conclusion

With the quality of software applications becoming the final arbiter in making an enterprise successful, taking the DevOps approach is crucial. However, since the whole process is hinged on executing comprehensive quality testing, the QA basics should be done right.

— Akshaya Choudhary

January 14, 2020