devopsy.kinsta.cloud

Category: DevOps Practice

Has the Pandemic Made DevOps Tougher or Easier?

How has COVID-19 impacted the way DevOps professionals approach their work?

The current, unpredictable economic climate as a result of the global COVID-19 pandemic has exposed a glaring need for organizations to be able to do more with less. They have fewer resources and even less margin of error now to maintain customer relationships, keep up the pace of innovation and stay ahead of competitors. This global crisis has shifted more end users toward digital services, increasing the pressure further on organizations to deliver robust digital services to both their customers and employees. Meeting that need in a short amount of time is, suffice it to say, extremely challenging.

All of this has shaken up norms for DevOps professionals and created an even greater need to accelerate continuous automation, break down silos between teams and cultivate greater cross-team collaboration, to help their organizations continue business as usual—in other words, a greater need for DevOps, period.

Let’s take a look at how today’s new normal has in some ways made DevOps transformations easier and more widely accepted, and in other ways made DevOps more complicated—and what leadership can do about it.

Improved Trust and Collaboration Among IT Teams

Trust and collaboration form the base of true DevOps cultures. Anything an organization can do to make collaborating easier and eliminate unfair advantages between teams makes DevOps easier to facilitate. If half your team is working in the office and half is working remotely, that is not an even playing field; there are advantages to sharing an office and being able to communicate in-person that those who work remotely don’t have.

It’s also a matter of trust. Trust is not always assumed for employees working remotely. People in the office might feel skeptical that those at home just aren’t working as hard as they are. The advantage of everyone having to work remotely for the last several months is that we’re now all on a level playing field; we’ve all been in the same work-from-home boat. That has eliminated unfair advantages and helped boost trust among team members.

The more you trust each other, the easier it is to collaborate and delegate work, which removes some of the typical hurdles for DevOps projects.

Increased Use of Automation

Alongside trust and collaboration, automation is another key pillar of DevOps. In the past, teams may have been skeptical about automating their work, figuring it was just easier to do it themselves.

But, the massive spike in demand for IT services this year put a lot of pressure on traditional IT teams to get services up and running, provision machines and troubleshoot access problems, among other things. The only way to scale up to meet these demands without being overworked was to adopt continuous automation.

Now automation skeptics have seen for themselves the value of automating tasks to make work more manageable during unexpected digital activity peaks.

Growing DevOps Skills Gaps Around Automation, Kubernetes

The good news is, DevOps projects have been excelling in the new normal thanks to these accelerations in collaboration, trust and automation. But the flip side of more automation is a greater need to pick up new skills for making automation work.

Those working remotely without kids to look after might find more free time to spend on leveling up their automation skills, such as learning Python and other new script languages. But those who have to pull double-duty between their own job and other household tasks demanding immediate attention—such as homeschooling and looking after young children—might be less likely to have that opportunity. This could put many people at a long-term disadvantage as skills gaps continue to grow around automation. We may be looking at the possibility of certain demographics of employees (i.e. those who aren’t currently raising families or school-aged children) having more access to skills and educational opportunities than those who do.

This is also an issue with Kubernetes. Enterprise adoption of Kubernetes is growing rapidly as the container platform of choice for managing dynamic multi-cloud environments. But adoption is moving so quickly that even the teams who work with Kubernetes can find themselves behind the curve before they know it. This Kubernetes education gap is getting bigger every day, and the people who may have time now to keep themselves informed about Kubernetes will be at a greater advantage than those who just don’t have the time for after-work training.

The Role for DevOps Leaders in This Moment

For all the instability going on today, DevOps projects seem to generally be in a good spot, thanks to growing trust and collaboration between teams and a greater acceptance of the need for continuous automation. But as we start returning to normalcy and heading back to the office, leaders must not allow their teams to lapse back into old habits.

Leadership will need to come up with new rules of engagement for working in the office to eliminate unfair advantages that used to exist. For example, at my company, we’ve established that once offices are fully reopened, meetings will only be held in-person if everyone invited is present. If one person invited to the meeting is remote, then everyone will join remotely. Organizations should look to adopt similar rules, as the transition from working virtually to in-office is going to be a long and challenging one, with not everyone returning all at once.

In addition, organizations and leadership teams need to dedicate more official work time to training and educating employees on new tech such as automation and Kubernetes to even the playing field, develop more highly skilled teams and close these skills gaps. Team leaders must ensure that everyone is on the same page and that it’s not just those who had the most free time while quarantining who are coming out ahead.

The behaviors we’ve picked up during social distancing—new opportunities for continuous learning, wider adoption of automation, elimination of unfair advantages for remote workers—are making DevOps better. But these are practices we have to continue carrying forward in the new normal and beyond.

July 14, 2020
Features or Quality? App Survey Shows Surprising Results

Software is an essential part of our everyday lives, but that doesn’t mean that people are always happy with the app experiences that they’re having.

We at DeepCode conducted a survey to learn more about what people really think about software quality today. Is it getting better or worse? How important are bugs and security vulnerabilities to the average user? The results are interesting, whether you’re building or managing software.

I’m going to highlight the data from the eight questions contained in the survey, provide some analysis on each question, and then summarize the key points that we can learn from the overall results.

People’s habits are baked in for a core group of apps: 78% use 10 or fewer apps each day, and 41% use five or fewer apps on a daily basis. When you consider the apps that we all use for activities such as email, web browsing, messaging, social media, entertainment and work, you can see that there’s only so much room for people to bring extra software into their daily routines.

Bugs and security vulnerabilities clearly have consequences: 92% of users lose confidence when they encounter them. People have high standards and they’re not willing to ignore issues.

Not only are software issues taken seriously, but they cause 93% of users to consider switching to a different app. With so many options available today that share a lot of similarities, software companies have to be careful not to push people in a different direction.

Considering making a change to different software is one thing, but 72% have actually done it because of bugs and security issues. User loyalty doesn’t always last forever.

A nice majority believe that software companies take quality issues as seriously as they should. Users know developers have a lot to deal with and are doing their best, but as we’ve seen so far, that doesn’t change the fact that they’ll have a negative reaction when your software lets them down.

There’s still a perception out there that all users care about are big, new features. Because of that, many times you’ll see software companies downplay bug fix releases as if they’re not worth mentioning. With 85% preferring bug/security fixes over new features, your best feature in any release is improved quality.

The earlier statistic about software companies taking quality seriously carries over to this question because 83% think it’s improving. It’s encouraging to see that extra attention on bugs and security issues is directly resulting in better software.

This one is rather evenly split, but if software quality is indeed getting better, then hopefully the percentage of those impacted will trend downward over time. It’s important to be cautiously optimistic here, however, because as software gets more ingrained in our lives through the internet of things and beyond, we’re opening ourselves to data and privacy threats that none of us are properly prepared for.

Quality Is Key

The results of this survey prove that quality software matters. Our brains may be telling us that, but if we’re honest, sometimes our hearts convince us that new features are the most important thing—no matter the cost. Users prefer bug/security fixes, and if they encounter software problems, they’ll consider switching. It’s really that simple.

Smaller software companies may not have the resources to innovate on the same level as some of the bigger players, but they can focus on improving the quality of what they offer. When a user has a bad experience with a competitor, your company can be known for quality and provide a safe haven for anyone comparing different options.

The users have spoken: You’ll be rewarded for building quality into the software development process.

July 13, 2020
Learning DevOps: All You Need Is a Browser

One of the most exciting things about a career in IT is the constantly changing landscape, providing almost infinite opportunities for learning. But this is also one of the great challenges IT careers: It’s just so hard to stay on top of everything. Hence, it’s not uncommon for people to learn some skills, find a niche and get comfortable there. The trouble is that comfortable niches get squeezed shut over time, and the opportunities fade away. This is where upskilling becomes important—to grow new skills, find a new niche and enjoy fresh comfort.

As DevOps has become such an important part of today’s landscape, DevOps skills are in high demand. Thankfully, the DevOps community recognizes the need to develop talent. As Dr. Richard Cook put it in the IT Revolution Symposium of Safety Culture, Lean, and DevOps, ‘’DevOps is not simply the practice of fixing problems or generating velocity. DevOps is also the practice of building a community of people who do DevOps.” There are many ways that this can work: on the job coaching and mentoring, meetups, conferences, training courses and certifications. The trouble is that many of those are difficult to scale due to demands on people’s time and places to get together, and that was before we faced the challenges imposed by social distancing.

Thankfully, the last few years have seen the rise of interactive online training platforms that provide an easy-to-access browser-based entry point for users. Behind the scenes, the platforms harness cloud-based infrastructure or containers as a service to provide realistic environments and scalability. Course content is generally structured in markdown or similar, along with files that define flow, mini-quizzes and any challenges that students are expected to complete. This allows training to be delivered at web-scale, reaching much larger audiences than in-person workshops and at a much lower cost per student. It also provides a safe environment for students to try things out and explore away from the packaged course flow. That safety is a crucial support for the third DevOps way of continuous learning by experimentation because it allows students to try things without any concerns about messing up an environment or running up a bill with a cloud provider. It’s also worth noting that a DevOps learning journey is generally more of an iterative process in smaller pieces because the three DevOps ways of flow, feedback and continuous learning by experimentation apply as much to learning DevOps as they do to practicing DevOps.

In some cases, course content has been open sourced, which allows an inquisitive student to see how things work behind the curtain (and maybe suggest improvements or fixes). Open source also provides an opportunity for course content to be modified and remixed to different environments and use cases.

Sample code for environment configuration from shift left on security module

Courses can also make use of API-based interconnectivity between systems through mechanisms including webhooks and identity tokens. That enables systems outside of the training platform, such as collaborative source control, to be incorporated into the overall experience. It also means that training environments can be customized to use the particular tools and practices adopted by an organization so that people can work in familiar ways (or get used to new ways of working).

Web-scale online training platforms first arrived to help people learn about tools and platforms. But now the range of things that we can do with them has expanded dramatically, which means they’ve become a valuable resource for learning more about DevOps. Whether you’re just getting started with DevOps or looking to develop deeper skills, there’s likely to be something online that can help. The courses also tend to come in bite-sized modules, meaning you can run through a whole bunch if you have time on your hands, or chip away that them while waiting for a build to complete or a huge upgrade to download.

July 9, 2020
Keysight Technologies Jumps into App Testing by Acquiring Eggplant

Keysight Technologies, a provider of tools to test and measure embedded systems and mobile computing devices, has acquired Eggplant, a provider of a platform that automates application testing, for $330 million.

Dr. John Bates, CEO of Eggplant, said the acquisition enables Keysight to expand the scope of its testing portfolio beyond hardware. Keysight traces its lineage back to Agilent Technologies, which it spun out of in 2014. Agilent was spun out of Hewlett-Packard in 1999. Keysight retains the test and measurement portfolio that began with HP back in 1939.

Bates said Eggplant, which has annual revenues of $38 million, will operate for now as an independent arm of Keysight. Over time, however, there should be increased opportunities to converge testing of applications software running on embedded systems that increasingly are being deployed at the network edge, he noted.

Eggplant’s Digital Automation Intelligence (DAI) platform is designed to automate the entire testing lifecycle process as part of a larger best DevOps practice. The rate at which application tests can be built and run winds up being a bottleneck as applications are being built. The DAI platform is designed to automate the creation of UI tests and then launch them against application code to eliminate as much testing friction as possible. IT teams can also track user behavior to create user journeys based on their interactions with applications and store tests created using modeling tools provided by Eggplant in its cloud service.

Eggplant has been investing in deep learning algorithms that, for example, automatically identify and classify user interface (UI) elements such as buttons and text fields across any platform and then generate all the automation assets needed to instantly run an automated test.

With the rise of DevOps, there’s now more application code to be tested than ever. As such, testing backlogs within many IT organizations are growing. The challenge is finding a way to thoroughly test applications without resulting in missed deployment deadlines. When those deadlines are in danger of being blown, testing typically is the first thing to be scaled back. Of course, when an application has to be rolled back, the primary reason often is because a key component was not tested properly.

Bates noted testing becomes even more complicated as organizations embrace microservices. The level of dependency between microservices spanning multiple platforms makes testing even more challenging, he said, adding IT organizations will need to rely on automated testing platforms to test applications at levels of unprecedented scale.

It’s not clear to what degree the COVID-19 pandemic may have accelerated demand for applications based on emerging 5G wireless services. Some organizations are forging ahead while others may be delaying initiatives as they cope with the economic impact of the pandemic. One way or another, a raft of applications running on a wide variety of edge computing platforms will need to be tested. Chances are good a much larger percentage of those applications soon will be tested by machines rather than humans that can’t scale to meet the challenge.

July 7, 2020
AWS Brings Machine Learning to Code Optimization

Amazon Web Services (AWS) has made generally available a tool dubbed Amazon CodeGuru that employs machine learning algorithms to recommend ways to improve code quality and identify which lines of code are the most expensive to run on its cloud service.

Peder Ulander, director of open source for AWS, said Amazon CodeGuru not only helps improve performance and resource utilization but also reduces the time and effort spent optimizing applications before and after they are deployed.

Amazon CodeGuru is based on a set of AWS machine learning algorithms to identify best practices for deploying code. It creates a profile of the code deployed and then surfaces recommendations to improve performance and reduce costs by employing the most appropriate tier of the cloud service.

That latter capability is critical because developers don’t always factor costs into deciding which tier of a cloud service to employ. Amazon CodeGuru enables IT teams to proactively optimize their cloud usage, noted Ulander.

Amazon CodeGuru can pull code from either GitHub or CodeCommit repositories, with support for other repositories planned. It requires developers to insert agent software developed by AWS into their code. Once a pull request is made, Amazon CodeGuru automatically starts evaluating the code using trained artificial intelligence (AI) models developed using data gathered from thousands of different open source software projects by AWS and its parent company.

Once the analysis is completed, Amazon CodeGuru will generate a graph showing such metrics as latency issues and CPU utilization rates, as well as human-readable recommendations to surface specific issues and remediations that include example code and links to relevant documentation for any line of code. Amazon CodeGuru can observe application runtimes and profile application code every five minutes.

Amazon CodeGuru has two core components. Amazon CodeGuru Reviewer automatically flags common issues that deviate from best practices and provides recommendations to fix them, including example code and links to relevant documentation. It then opens a pull request and automatically starts evaluating the code using machine learning models to identify the line of code, specific issue and recommended remediation, and provides access to a pull request dashboard that lists all the information gathered by all code reviews.

IT teams can provide feedback on CodeGuru Reviewer recommendations by clicking on a thumbs up or thumbs down icon, which helps improve recommendations over time using machine learning.

The second component is Amazon CodeGuru Profiler, which identifies the most expensive lines of code by analyzing the runtime behavior of their applications. Armed with those insights, IT teams can identify and remove code inefficiencies, improve performance and decrease compute costs.

IT teams today spend an inordinate amount of time debugging code to address a broad range of issues. The paradox is the more applications they deploy, the more time they spend debugging. Perhaps the time has come to finally let machines discover code issues in the hopes that developers will use their time writing new code, not fixing it.

July 7, 2020
How No-Code Software Development Speeds Digital Transformation
More organizations are democratizing software development through no-code solutions that empower anyone to write applications

In today’s fast-paced and digital business world, organizations must revise their goals and processes to achieve digital transformation and remain a viable business.

However, most transformation efforts fail. Recent McKinsey research shows that 70% of complex, large-scale change programs don’t reach their stated goals. For most organizations, the complexity of the technology environment and the inability to swiftly implement necessary changes are major roadblocks.

No-code solutions allow organizations to stay agile and accelerate their strategy execution by empowering power users (or business users) and developers to rapidly develop applications. Such solutions also improve the ability of IT to respond to business demands, shorten time-to-market and accelerate digital transformation.

What Is a No-Code Solution?

A no-code solution mitigates the need for manual programming in application development. Instead of writing lines of code, users can develop applications through simple point-and-click on specific components that can be arranged into logical sequences to create functional and feature-rich applications.

The inherent value no-code software development is it accelerates and democratizes the application development process. With such a solution, your power users can build applications to solve critical business problems and automate tasks to increase productivity.

5 Benefits of No-Code Software Development Solutions
- Reduce the load on IT: As mentioned before, no-code solutions allow business users to build applications without any coding knowledge. By enabling such a change, the solution reduces the burden on the understaffed IT department. Applications to solve business challenges and increase productivity can be built quickly without relying on IT. This in turn allows the IT department to dedicate more time to business-critical apps and projects.
- Accelerate development time: No-code solutions enable business users to take application development into their own hands; they don’t have to wait for their requests to be answered by the IT department. Tasks that used to take months (even years) to complete can now be done in a few hours or days, depending on its complexity. That is the level of acceleration a no-code solution can provide to the application development life cycle.
- Ensure more targeted outcomes: The point-and-click configuration of no-code solutions empowers the business users and developers to quickly build solutions to meet their exact requirements and specifications. Such applications then can be updated on the fly. These aspects are important to keep the business competitive and agile. While a no-code solution allows the development of applications for immediate impact, it can also prove to be cost-efficient in the long run.
- Fight shadow IT: When the IT department is unable to act on the requests of business users, those users start seeking solutions on their own. With the rapid rise of SaaS, they can quickly find an application to meet their needs. However, adopting such applications can lead to security vulnerabilities. A no-code solution enables businesses to eliminate the problem of shadow IT by allowing the business (power) users to develop their solutions to meet specific business needs while enabling IT to centrally control the data and user accesses.
- Enable experimentation without risks: Experimentation is an essential part of digital transformation. No-code solutions allow organizations to test their ideas on a small scale to eliminate the setbacks. It empowers business users to experiment with their ideas, iterate projects efficiently and create solutions that can transform organizations and keep them adaptable to changes in the industry.
To meet the challenges of digital transformation and remain competitive in the marketplace, organizations need to create an environment that enables agility and flexibility of the internal workflows and customer-facing operations. When powered by a comprehensive no-code solution, organizations can create an infrastructure that allows them to transform and innovate faster, which generates new growth opportunities and provides a competitive advantage.
July 7, 2020
4 Mobile DevOps Must-Haves

Mobile DevOps requires a robust and streamlined strategy for success

The mobile revolution of the last 20 years has radically changed our everyday lives. That’s not just the way we communicate, but also the way we find information, purchase goods and services, entertain ourselves and more. This has gone in tandem with great technological advances elsewhere, including small-business VoIP. Now it’s never been easier to organize a business teleconference or simply catch up with friends and family, wherever they happen to be.

Recent years have seen mobile apps scale new heights of technological achievement. This plethora of new apps has changed the way we work, play and chat. But that’s not all. It’s also changed people’s expectations—and it’s up to businesses to respond to that. Consumers expect apps tailored to suit the different aspects of their lives. This puts a great deal of pressure on businesses and other organizations to meet these higher and more demanding expectations.

That’s why so many are taking advantage of the opportunities offered by mobile DevOps. In a nutshell, the purpose of DevOps is to facilitate enhanced collaboration between project managers, mobile developers and ordinary employees. This helps businesses to meet their goals more effectively, while also ensuring that users enjoy the best and most convenient experience possible. It also means that businesses don’t have to go through the hassle of using native apps to create new hybrid products, greatly simplifying their tasks.

But without a robust and streamlined strategy in place, mobile DevOps won’t automatically deliver the goods. You need to have a solid understanding of a range of different factors. These will include user preferences, development trends and software delivery. One thing that is clear is that consumer expectations are changing at a remarkable rate and you need to ensure that your offering is up to par. Agility is the watchword, and your DevOps strategy needs to have this flexibility built-in.

Elements for Successful Mobile DevOps

Here we’ll take a look at four must-haves of any streamlined mobile DevOps strategy to help you get started. Read on to find out more.

Planning

It might seem like an obvious point to make, but thorough planning is the indispensable foundation of any effective mobile DevOps strategy. Having said that, you’d be surprised just how many firms fail to take this basic requirement properly into account. It doesn’t matter exactly what your specialism is—whether it’s HR software or telemedicine app development—your project must be planned in fine detail.

Get everyone who’s working on the project together. That means all stakeholders, from your developers and testers to your operations team and others. It’s then that you can start to map out what form your project will take. It’s a good idea to get clients involved at this early stage as well, because it’s imperative to keep their needs in mind at all times. Think about what everyone requires from the project (including quality control requirements) and how to deliver it. Consider the potential risks involved and what steps you might take to mitigate these.

People and Communication

It’s the same with any project—unless you’ve got the right people on board and the right chemistry between them, you’re almost certainly doomed to fail. Your team, therefore, is of the utmost importance. Mobile DevOps inevitably involves a wide array of different people with unique skill sets, who will make their own particular contributions to the project. You should prioritize finding the right mix and maintaining morale across the board. This will go a long way to ensuring harmonious working between the different wings of your team.

Part of keeping team morale high is making sure that communications between different parts of the team are smooth. DevOps projects, as we’ve noted, tend to have quite a large number of people working on them. There is a danger that different teams can become somewhat siloed. That’s where each smaller element of the team fails to work coherently with those around it. You should, therefore, make a concerted effort to keep the different groups working on your project collaborating closely with one another. In this way, your people are sure to add up to more than the mere sum of their parts.

Testing, Monitoring and Delivery

Continual testing, monitoring and delivery are all essential to ensure that deployment is smooth and free of avoidable errors. Every build should be subject to rigorous testing so that any snags can be discovered and ironed out. Monitoring must be similarly thorough at each step of the way. This helps to keep the production process stable so that any unexpected hitches can be dealt with more effectively when they arise. Continual testing and updating are more important than ever, given the advent of the internet of things and its always-on nature.

It’s also important to remember that speed is of the essence when it comes to mobile DevOps. The more effective your testing, monitoring and delivery processes are, the quicker you’ll be able to roll out new apps—in other words, increasing software velocity—and you’ll be able to do so with confidence that they’ll be reliable, user-friendly and secure. This will help to improve the overall efficiency of the development process, as well as boosting user and client satisfaction. It will also improve return on investment while helping to minimize the risk of cost overruns.

Quality and Efficiency

Striking the right balance between quality and efficiency in mobile DevOps may be top of mind for you. We’ve already alluded to the importance of efficiency in DevOps processes. Maximizing quality in the development of new apps can also do a lot to improve efficiency, save money and cut out unnecessary expenses.

After all, there’s no getting away from it: development can be an expensive business. A laser-like focus on quality can prevent avoidable complications in the development process. Crucially, it also helps to maintain user satisfaction (always a vital consideration). Think about telemedicine app development, for example—a particularly fraught area. A telemedicine app that’s unreliable, prone to errors or generally shoddy could have a devastating impact on a company’s reputation. Robust DevOps tooling not only allows for better quality but also enhances efficiency by freeing up developers and testers to work on other tasks.

July 7, 2020
SREs Tasked With More To Improve Digital Experiences
The digitization of the enterprise has never moved so swiftly, and never have enterprise environments been as complex to manage. And, never have more businesses been as dependent on their infrastructure and operations being unfaltering.

According to a new survey and accompanying report from Catchpoint and the DevOps Institute, site reliability engineers (SREs) and teams still struggle with effective SRE processes that would help these teams improve their system reliability, incident management and end user/customer satisfaction.

For instance, the survey found that 53% of respondents reported being brought in too late into the application life cycle. Most respondents said that they are currently spending 75% of their time focused on operations and very little of their time on development objectives.

That heavy focus on ops comes at a cost by increasing the ongoing costs associated with owning and operating their systems and infrastructure. Moreover, in recent months, perhaps because of increased remote work, Ops-related activities have increased by 10% overall among those surveyed.

Since the start of the COVID-19 pandemic, the number of SREs who believe they will be working remotely in the next year jumped to 50% from only 19% who thought so before the outbreak of the novel coronavirus.

When it comes to performing their duties, more than half of the respondents cited the change to remote working causing challenges when it comes to attaining a balance between their work and their life.

Additionally, while 9% of respondents felt incident management has improved, 41% said that half or more of their work is focused on managing mostly manual, repetitive and tactical tasks that could likely be automated. Another 52% said they spend too much time debugging.

The report provided a few suggestions for teams:
- Be sure to include consideration for not only your code but also the networks, third-party services and delivery chain components to evaluate how well the three observability pillars are applied through this new digital experience observability lens.
- Work to be included earlier in the development process should shift reliability further left to reduce cost, increase team alignment and identify constraints that can be removed.
- Turn newly surfaced or previously ignored challenges into strategic differentiators. Focusing on challenges such as morale, employee experience, work/life balance and employee engagement and sentiment may showcase a company’s employee-first mentality to attract or retain top talent.
As we covered in “Digital Transformation Efforts Hindered by Lack of Upskilling,” there are no digital transformations without staff transformations and the same is true for practices such as DevOps and SRE. And it’s that last point that may be one of the biggest inhibitors to SRE teams getting from where they are today in maturity to where they want or need to be. An earlier survey from the DevOps Institute, the “2020 Upskilling: Enterprise DevOps Skills Report” found that 58% of enterprises have a tough time actually finding those with the right DevOps skills, and 48% said it’s difficult to retain skilled DevOps professionals.
July 3, 2020
Fastly Facilitates Observability at the Edge

Fastly this week announced it is adding the ability to collect tracing, customizable logging data and both real-time and historical metrics from a serverless computing framework designed to be deployed on edge computing platforms.

Company CTO Tyler McMullen said the goal is to make it easier for IT to bring observability within the context of a DevOps to an edge computing platform.

The Compute@Edge serverless compute platform enables IT teams to employ functions to execute code on an edge computing platform versus having to install virtual machines or containers. Those edge computing platforms are connected to a content delivery network (CDN) managed by Fastly.

McMullen said that approach provides a way to deploy microsecond applications at the edge while still attaining observability in keeping with best DevOps practices. Otherwise, edge computing platforms become yet another black box that provides IT teams with no visibility.

DevOps teams can send real-time logs to 27 and counting supported endpoints. Default log fields are automatically exposed to better determine the root cause of any issue. DevOps teams can also capture custom event details.

Metrics such as CPU and RAM utilization can also be surfaced either in real-time or on a historical basis. The Compute@Edge service also honors request tracing parameters by maintaining them when they enter and leave the Fastly platform. Developers can tag individual end user requests with unique identifiers that can be shared with third-party platforms such as Datadog.

Currently available in beta, Compute@Edge makes it easier for IT teams to employ a serverless computing framework to drive event-driven applications at the edge, McMullen said. Latency issues that arise when applications attempt to access cloud services are pushing more organizations to deploy real-time applications at the network edge. Functions running on a local serverless computing platform enable IT teams to achieve that goal in a way that consumes the smallest amount of IT infrastructure possible, he added.

With the rise of 5G networking services, it’s now only a matter of time before the number of platforms on which a DevOps team needs to deploy code expands significantly. Most DevOps teams are already challenged by all the unique platforms to which need to deliver code. Edge computing could potentially exacerbate those issues because each edge computing platform tends to have unique attributes. A common serverless computing framework running on each of those edge computing platforms could help streamline continuous delivery.

Of course, it’s too early to say what impact the downturn on the economy will have on edge computing projects. In theory, at least, organizations are gearing up to deploy these applications in anticipation of wireless 5G connectivity services being widely available and affordable. Chances are high, however, with more organizations not willing to send people to install applications on those endpoints manually, reliance on DevOps processes and CDNs to automate application delivery at the edge will become a requirement.

July 2, 2020
SDM and the DevOps Delusion of Connected Organizations
How Software Delivery Management Clears Up the Confusion of Embracing and Implementing DevOps

Since the term was coined back in 2009, it wouldn’t be a stretch to describe DevOps as an impactful if not tectonic shift in software development and delivery in the past two decades. The move to implement DevOps has encouraged, among other things, better collaboration between siloed Dev and Ops teams, more reliance on automation, more focus on culture and better use of feedback loops to refine delivery processes.

In theory, DevOps has been a game-changer. But, in practice, its usefulness is more difficult to define. As DevOps enters its teenage years, the idea of a fully integrated software delivery function aligned toward a common goal of generating business value is more illusion than reality.

Are DevOps teams themselves as connected as they should be? The reality is that developers and operations personnel tend to have their own versions of “dev DevOps” and “ops DevOps,” working against each other inside supposedly integrated teams. Though they may have set up deployment pipelines, each side tends to use its own tools, access its own information and follow its own cadences, leading to occasional missed handoffs and delays in delivery schedules.

Looking across the enterprise, DevOps cultures fray further. A perfect DevOps practice envisions teams in different departments, business units and geographies all in sync, delivering value via software on a reliable cadence. In reality, enterprise DevOps is difficult to pull off because most organizations haven’t implemented shared languages, comment processes and best practices across all of their teams with management buy-in.

Then there’s the issue of connecting DevOps functions with the rest of the organization. Some definitions of DevOps extend the concept of collaboration to other stakeholders beyond conventional engineering functions, such as quality assurance, testing and security. But how extensively does a DevOps culture tie together the goals, needs, resources and processes of others in the organization that rely on software delivery, such as product marketing, sales and executive management?

Delivering Better Software

Gartner describes DevOps as being focused on “rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.” In other words, delivering faster and in a more organized manner. But has DevOps helped software-first organizations deliver better software? Has it helped them institute the right processes to deliver the right software at the right pace to drive the most value possible to the organization’s bottom line? Paraphrasing the “If a tree falls in the forest …” proverb: If you deliver software and no one is there to consume it, have you truly delivered value?

Even if you’re doing DevOps relatively well, there’s a level of integration that’s missing from today’s software cultures. It’s the mission to tie together all functions of software delivery—not just those relating to what goes on in the labs. It’s the commitment to do more than just deliver better metrics. It’s the mentality to define everything relating to software delivery as a discipline all its own, like finance or sales—not just serving other disciplines.

A new technology category is emerging that aims to build on what DevOps has accomplished and extend those gains across the software delivery function. It’s called software delivery management (SDM). An SDM strategy is based on four foundational pillars that elevate software delivery to a core business priority, reflecting the level of importance software has achieved in today’s business environment:
- Common Data – All information within and around software delivery activity is captured and stored with a consistent domain model to enable and facilitate connections to processes, shared insights and collaboration.
- Connected Processes – Processes orchestrate software delivery and connect functions together to efficiently bring ideas to market with maximum value and adoption.
- All Functions Collaborating – All functions and teams within and around the software delivery organization work together to amplify value creation efforts.
- Universal Insights – Visibility and insights enable understanding and continuous learning from data across, up and down and throughout all functions in the organization.
Driving Improvements Across Organizations

Adopting an SDM strategy on top of an existing DevOps culture can help an organization in a number of ways.

Having disconnected tools, disconnected data and a lack of common language make it difficult for one side of the organization to know what the other wants. Even in mature DevOps implementations, software delivery ends up being a patchwork of different processes for different teams.

It’s also difficult to determine if our teams are delivering the right end product if there’s no shared visibility and insight. SDM helps by establishing common data and common processes, giving visibility and insights across teams of different maturities, different tools and different technologies so you get all functions to collaborate. That way you can be sure you’re not just deploying more—you’re actually delivering continuous value.

You can’t manage what you can’t measure. What SDM offers is a model to understand how you’re performing with DevOps by and large, what teams are performing well and what teams aren’t, and how you can leverage those insights to improve.

Tips for Implementing SDM

Here are five ways SDM build on the successes of DevOps:
- Integrate your tools: Disconnected toolchains make it difficult, if not impossible, to orchestrate a delivery process end to end. Try to get DevOps tools onto a common platform where they can share information across teams and organizational functions.
- Capture data: Ensure you’re establishing an audit trail and capturing data on events and actions that are taken across that end-to-end process. Then collect those data points in a common data store as normalized objects. Making common data accessible across functions allows you to, for example, reconcile a particular support request to the right user story and commit to the right change that is being deployed out to a server.
- Don’t fail to communicate: Once you’ve created your data store, establish a strong relationship and regular communication with the business side of the organization. Continuous delivery isn’t just for developers anymore; software delivery functions have to address business needs. That can’t be done without high levels of communication.
- Establish KPIs: You should have a taxonomy or hierarchy of business objectives you’re trying to achieve with your DevOps implementation. Establish the hypotheses that can achieve those objectives and then integrate the features/user stories or implementation-level entities that will drive you toward them.
- Leverage observability practices: This needs to be done so you can measure those performances against KPIs. If you believe that updating your user interface will increase the amount of time users spend in your SaaS application, you need to establish what that target KPI is. Then, as those changes are delivered, measure, analyze and adjust to continue to drive those toward the hypothesis.
Conclusion

DevOps has taken software delivery a long way and implementing an SDM strategy can take it the rest of the way. It won’t change DevOps, but it could reinvigorate the practice. Deploying both strategies in concert, software delivery management and DevOps can focus less on automation and tools and more on the outcomes and on the people and steps involved in driving those outcomes.
July 2, 2020