devopsy.kinsta.cloud

Tag: developers

DevOps Tools Democratize the View From Both Sides

How modern product decisions platforms marry the key metrics of features changes to organizational KPIs

In 1967, Joni Mitchell released one of her most iconic songs, “Both Sides Now.” The song was inspired by the book, “Henderson the Rain King,” in which author Saul Bellow writes about flying to Africa and looking out the plane window, “Look at those clouds down there; it’s very strange to look at the clouds from up above them. I remember as a boy having dreamed up at clouds a lot and having seen the cloud from both sides now, I suppose I shouldn’t really be amazed by anything.”

Although not her intention and slightly before its time of popularity, the song speaks quite accurately to the tensions between idealized DevOps and the reality on the ground that many organizations are struggling through. On paper, the core tenant of DevOps is about cooperation, seeing problems and processes from multiple team members’ perspectives from each side, but this is easier said than done.

“But now old friends they’re acting strange
They shake their heads, they say I’ve changed
Well something’s lost, but something’s gained
In living every day.”

The Unicorns and the Rest of Us

Some of today’s most successful and disruptive companies—including Google, Netflix and Facebook—have taken their market-leading positions precisely because they have developed strategy and culture around DevOps. It has been part of the company DNA since the beginning and every employee is bought into it. This means fast, agile development and experimentation is part of the culture.

While many companies would like to capture some of the benefits that unicorns have realized from implementing these development methodologies, for many, this simply is not an option. There is legacy infrastructure, processes and people—who are sometimes the hardest to change. Often DevOps is embraced in small pockets of a company, by teams with newer members working on new projects. The mindset shift that needs to happen to have DevOps—and everything that comes along with it—become part of a company’s culture takes time, commitment and perseverance. However, a good way to start is by demonstrating the fresh, diverse perspectives that can be gained through experimentation and progressive exposure to encourage wider adoption.

Leveling Up

One of the ways modern app delivery, operations and business management teams at organizations all along the adoption spectrum are achieving governance, operational awareness and control at speed is by wrapping new code deployments in feature flags and using a centralized platform to control progressive exposure to users.

By themselves, feature flags are not new. What is new is the centralized and externalized control plane as a service and, newer still, the idea of observing system and business KPIs at the user session or request granularity level for feature flag-controlled decisions.

When something is rolled out to 5% of the users, it is not likely to light up global ops or business metrics dashboards, even if it is a bit broken—and that makes people cranky. If instead, tools are in place to monitor the KPIs within that 5% population and compare it to the other 95% looking for divergence, you have a much more powerful early warning system.

These new centralized platforms also extend observability to stakeholders beyond the few wizards driving orchestration and ops teams watching dashboards. An anti-pattern to the local control autonomy spiel modern DevOps patterns call for, this wider visibility protects against local optimization traps in which one team improves its KPI while degrading other KPIs it doesn’t know or care about.

It can be beneficial to have the idea of key metrics tied to a feature and organizational metrics that look after larger organizational concerns. This inspiration can be traced back to what LinkedIn does with its XLNT experimentation platform, where it calls the organizational metrics “guardrail KPIs.” By always tracking a set of metrics that are critical to the business as a whole, organizations gain a clearer view of the impact that both the granular updates and the larger rollouts are making to the business.

As Joni said in all her wisdom:

“I’ve looked at life from both sides now
From up and down, and still somehow
It’s life’s illusions I recall
I really don’t know life at all.”

No team or organization can know everything all the time, but we can build in visibility to the process of rolling out functionality to our users and create a shared vision of our intentions and the results we achieve. I would argue that if you do look at DevOps from both sides, up and down, you will know the benefits.

— Dave Karow

June 11, 2019
Successful Digital Transformation Starts With Developers

Digital transformation (DX) continues to be a primary focus as companies both large and small look to become more agile, improve and accelerate the delivery of product and service offerings and enhance data-driven business decisions. The C-suite typically leans on IT departments and developers to champion such transformations, designing the software and tools that will lead the experience both internally with staff and externally with customers. The challenge often lies in the fact that most organizations lack the software resources to drive a successful transformation. In addition, research has found that 45% of executives don’t know where to start with DX projects, resulting in added pressure on the developers who hold the technical knowledge but may lack the managerial expertise for a successful rollout.

So, with IT having the opportunity to be the hero or the scapegoat of a DX initiative, where should development teams start? Typically, digital transformation requires development transformation, so you can start at home, by modernizing the way you develop and deliver software. Doing this also significantly improves the odds of a successful digital transformation and puts development in the driver’s seat.

Here are four factors to prioritize before kicking off a DX project:

Buy vs. Build

A DX initiative requires a number of digital tools and software applications, some of which can be purchased through third parties while others may need to be built in-house, depending on the desired goals of the program. Organizations must determine whether they want to build or buy new software solutions, and the answer is almost always mixed. Most developers believe that each application can be built in-house, while the C-suite often encourages purchases from a third party to accelerate adoption. Before starting to code, ask yourself if the solution you need should be bought or built. Oftentimes, the same goal can be achieved through a purchased solution, empowering you and your team to spend more time customizing those solutions rather than starting from scratch while focusing on the projects that will have the biggest impact on the business—ultimately accelerating time to completion.

Accelerated Rate of Change

Once applications are built and available to the public, you can expect bugs to be identified and requests for improvements to be made at an accelerated rate. Developers are constantly making software updates, but when applications are being used to support DX, the rate of change for business requirements is going to speed up, especially when those applications are customer-facing. Developers will need to learn fast and iterate quickly, so it’s important to establish an agile culture within your team.

Adopting a DevOps philosophy often will be the most successful approach, as it enables your team to test and troubleshoot quickly and enact change across the platform. This approach also assists the rest of the organization in adopting DX practices, delivering a more seamless experience and universal data-sharing. Developer teams must be wary of traditional quarterly or annual planning cycles that create silos, slow agile processes and hinder successful implementations. By breaking down these silos, your team will gain better insight into what is and isn’t working and enable swifter improvements, creating a culture that embraces the changes that come with DX.

Modular Software Architecture

Software architecture is incredibly important, as it directly impacts the team’s ability to react to rapid change. A more loosely coupled, modular architecture puts the developer team in the best position to evolve quickly with fewer dependencies, enabling them to make updates and replace components over time to meet business objectives and customer demands. The ability to reconfigure or replace components without having to recode the entire system also assists in build-versus-buy decisions, with developer teams purchasing add-ons to incorporate into a system and solve problems quickly.

DX Outside of Organizational Barriers

We work and collaborate in a digital ecosystem. External APIs, third-party data-sharing and interoperability are all requirements as organizations roll out new tools as part of a DX initiative. DX comes down to building a digital ecosystem that flows outside of the organization, whether it is employees working remotely or customers integrating your tools into their existing solutions. Your company’s software needs to accommodate these capabilities to enable a more seamless and well-rounded DX approach.

DX is a Journey, Not a Destination

A successful DX initiative should be seen as a culture shift, not an end result. The digital world is not static, and DX is a practice that enables an organization to learn fast and be lean and nimble. As soon as you’ve reached one milestone, there’s a whole new set of rules to play by to get to the next, requiring the developer team to recalibrate. By taking a realistic, process-oriented approach, the developer team will have the mindset and tools necessary to make DX successful.

— Jeff Fried

June 10, 2019
Why Workload Security Is Not Just for IT Anymore
Once upon a time, workload security (which means making sure an application and its environment are configured and deployed securely) was something that developers didn’t have to think much about. Developers’ only real security responsibility was to write secure code. After they passed the code off for building, testing and deploying, it was someone else’s job (specifically, the IT department) to secure the workload of which the code was a part.

That’s no longer the case. Today, workload protection is the responsibility of the entire DevOps team, not just IT engineers.

Let’s explore why, and what this change means for developers.

How Security Problems Flow Down the CI/CD Pipeline

To understand why workload protection has become everyone’s responsibility, you have to understand how DevOps and CI/CD have given rise to new types of security challenges.

In an organization that has embraced DevOps, code is intended to flow continuously, in a so-called CI/CD pipeline, from development to testing, to building and, finally, to deployment. To keep the CI/CD pipeline flowing smoothly, DevOps teams typically strive to standardize and automate as many processes as possible.

From the perspective of efficiency and reliability, standardization and automation are great. They are key to enabling continuous software releases.

When it comes to security, however, standardization and automation have a downside, which is that a configuration problem introduced at one stage of the pipeline can flow down the pipe and reach production environments easily without anyone noticing.

This is true for two main reasons. First, standardization and automation minimize the amount of human intervention and oversight that go into the CI/CD process. Again, that’s exactly the point, and it’s a benefit in most respects. But when it comes to security, less human intervention means a greater chance that a security problem will go undetected (particularly if you don’t have automated security tests or audits in place to catch the issue).

The second major risk associated with standardization and automation within a CI/CD pipeline is that sometimes, developers might set a configuration that they don’t intend to be used in production, but is pushed into production nonetheless by the automated pipeline.

For example, developers might place code inside a container to help with testing or staging, without intending for that same container to be used in production (instead, they assume the code will be repackaged before being deployed). Because they don’t intend for the container to be used in production, they don’t use a secure configuration for it. Maybe they let it run as root, for example. Then, if communication breaks down and a release automation tool pushes that container into production without changing the configuration, a container with a security flaw will end up being deployed.

To learn more about security and compliance for DevOps, check out our recent webinar.

Extending Workload Protection Beyond IT

In a perfect world, the IT team would be able to catch these flaws. But the reality is that in a fast-moving CI/CD environment, it’s not realistic (or fair) to expect IT alone to make sure that workloads are configured securely before they are deployed.

Instead, the entire DevOps team needs to take responsibility for workload security.

What that means specifically will vary from organization to organization, but in general, extending workload protection beyond IT means the following:
- Making sure that developers (and not just IT engineers) understand workload security best practices and why they are important to follow at every stage of the CI/CD process.
- Establishing and enforcing (via automated audits) policies for how workloads can be configured at any stage of the CI/CD pipeline. For example, the DevOps team as a whole might agree not to run containers as root, even if it’s only in pre-deployment.
- Enabling runtime protection by scanning for vulnerabilities that appear within applications and environments once they are live.
- Securing data at all stages of the CI/CD pipeline and scanning data for signs of intrusion or malicious code.
- Performing continuous security monitoring and vulnerability detection (both pre-deployment and post-deployment) to catch issues as quickly as possible, even if they have slipped through the cracks of earlier security tests.
Conclusion

It would be nice for developers if workload security was not their responsibility. But in the age of CI/CD and DevOps, they no longer can hand off that burden to the IT team. The IT team still has an important role to play in making sure workloads are deployed securely, but effective workload security for DevOps starts early in the CI/CD pipeline—with developers. Code moves too quickly down the pipeline for developers to assume that they can safely do one thing with a workload and have the IT team change it before the workload is deployed.

Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

Sign up for a free trial of Symantec CWP.

— Chris Riley
June 6, 2019
Textbook DevOps vs. Real-World DevOps

DevOps is one of those things—like Marxism or baking macarons—that is easy to understand in theory, but much messier to implement in practice. Real-world DevOps rarely aligns with textbook DevOps or the DevOps practices that organizations should follow in theory.

That is true for a number of reasons. Let’s walk through some of the biggest below.

Your Company Is Not Organized in the Way DevOps Theory Assumes

According to DevOps theory, every company has an IT department and a development department. Doing DevOps boils down to making those departments work well together.

The reality, of course, is that not all companies organize their staff or technical operations in this way. Some don’t silo developers and IT engineers by default. Others (especially smaller companies) don’t have developers or IT staff on hand at all; they outsource that work.

These companies can still benefit from DevOps principles such as collaboration and automation. But they should avoid fixating on DevOps teachings regarding the organization of technical work.

Real DevOps Skills are Hard to Find (And Expensive to Obtain)

“DevOps engineer” is now a trending job title. But few technical training programs have caught up with the demand for DevOps.

Most universities still silo majors and courses in software development away from those that focus on IT. Other types of technical training programs function similarly.

What this means is that it is more difficult to hire a DevOps engineer, or other technical staff with a broad set of development and IT skills, than it may first appear. DevOps engineers exist, but they are usually experienced staff who learned their real-world DevOps skills on the job. They’re more expensive to hire and difficult to poach from their current gigs.

Full Automation Is a Pipe Dream

The DevOps mantra tells us that we should automate everything, from software testing and builds to deployment, production-environment monitoring and incident response.

Automation is great in theory. But the reality is that you can never automate everything. Human engineers will still need to respond to problems occasionally, or to unanticipated issues that arise during testing, deployment and production management.

An important point to emphasize here is that even if you successfully automate virtually all of your processes, the mere fact that human engineers must be available to respond when something does go wrong undercuts the idea that you can rely on automation alone. Humans still have to watch the automated processes, even if they rarely need to intervene. The simple act of watching and being available to respond when necessary is a significant burden.

Agility Conflicts With Simplicity and Reproducibility

In some respects, DevOps is a contradiction. On the one hand, it prioritizes agility and scalability. On the other, it emphasizes simplicity and reproducibility.

What this means in practice is that DevOps teams adopt microservices and containers in the interest of maximizing agility. But microservices and containers are much more complex to manage than monoliths and virtual machines.

I suspect the reality is that most DevOps organizations end up erring toward more complex technologies and architectures. They ultimately find greater value in them than they do in keeping things simple.

Still, the idea that you can be agile and be simple at the same time doesn’t apply well in the real world. (And sure, automation, infrastructure as code and the like can help in simplifying the management of complex agile technologies, but they only go so far.)

Most Organizations Still Aren’t Doing DevOps

If you spend your time surrounded by other people who have adopted DevOps and implemented it successfully, it’s easy to assume that the rest of the world is like you.

The reality, however, is that we’re now a decade into the age of DevOps, and yet a majority of organizations have made only halting steps toward implementing basic DevOps processes. If DevOps were half as easy to implement as it appears to be when you read the latest book about how to do DevOps, many more companies would be doing CI/CD by now.

Conclusion

DevOps delivers real benefits, and it’s important to continue preaching the DevOps gospel to organizations that can benefit from DevOps philosophy and practices.

However, it’s important to balance the conversation about DevOps with the reality: Real-world DevOps is much messier than it often seems in theory. Not many organizations have the configuration or resources to do textbook DevOps.

— Chris Tozzi

May 30, 2019
Growing Pains for Containers, Data Centers Call for Better Management

Containers have taken the tech community by storm with their ability to drive agile and effective innovation. Compared to the rigid nature of virtual machines, it’s no wonder developers and IT teams have flocked to containers and their flexibility. By dropping the strict hardware focus of virtual machines, containers are allowing teams to surface innovation into operating systems and create an elegant solution for moving code.

As we continue to see the adoption of container-driven operations grow, the industry’s excitement for innovation is overshadowing a problem growing at the same scale: over-containerization. Whereas virtual machines traditionally provide a predictable understanding of hardware performance, containers are not in touch with the hardware native to their operating system. As a result, containers are often left to fight for control over one system. In these instances, data centers are inefficiently distributing energy as they experience drastic power pulls that drain energy and dollars.

While this might sound like another bout of industry growing pains, without a proper reaction, this can cost companies millions of dollars lost to inefficiency. Just as teams are investing in the latest orchestration features to manage their virtual environments, it’s time to consider technology’s hardware roots and monitor containers’ effect on data center functionality. Data center management tools provide a simple solution to this problem by monitoring power usage, gauging utilization across data centers and presenting data needed to make a winning strategy.

Monitoring Power

Data center management tools provide granular insight into power consumption, with options to monitor per server, rack, workload and application. Given the hyperfocused, often greedy nature of containers, power monitoring allows data center managers to identify how much energy containers need and how to best allocate it across multiple containers. This gives managers the information they need to create a centralized management policy for server energy consumption and avoid power pulls from hungry containers in the future.

Gauging Utilization

While the industry’s initial concern is containers’ tendency to pull power away from the majority of an environment, there is an opportunity within this dynamic. Data center management tools offer visibility into uptime and cross-platform consumption levels, which presents a chance to identify underutilized servers that could support more containers. Given that containers are far easier to migrate than virtual machines, server migration is likely to occur more often and data center managers will need to provide a recommendation quickly. With enough insight into the long-term, low utilization trends, teams will be able to consolidate and balance workloads across existing devices.

Adjusting the Data Center Strategy

Data center management solutions solve an immediate power problem, but what are they doing to keep up with the ever-evolving enterprise space?

Some data center management tools offer features that visualize power consumption and predictive modeling for efficient planning. With these insights, not only will IT teams be able to give power to containers across their environment, but they also will be able to save resources and lower operational costs for years to come. This presents a win-win situation for developers and managers, in which containers are given the energy to power innovation and data centers are operating at maximum efficiency.

As we look to the future of containers and data center management, it’s in the best interest of enterprise companies to invest in their hardware just as they have invested in containers. As the industry continues to become focused on virtualization, a solid, foundational understanding of data center performance and capacity will be key to long-term success.

— George Clement

May 24, 2019
Survey Finds CI/CD Adoption Has Long Way to Go

At the KubeCon + CloudNativeCon Europe 2019 conference, Codefresh published the results of a survey of 130 developers that finds not only are nearly a third (32%) not using any type of continuous integration/continuous development (CI/CD) platform at all, but 60% said their organization has yet to take full advantage of automation to accelerate application development and deployment.

In fact, according to the survey, it takes more than two weeks for two-thirds of developers (64%) to push a commit into a production environment. Additionally, the survey finds that for 39% of respondents, less than 10% of their company’s processes are automated from Git commit to code to production.

Not surprisingly, only 19% of developers said they deploy code at least once daily. Roughly a third said they release code into a production environment only once a quarter. At that rate, it may be difficult for those organizations to justify investments in a CI/CD platform.

Dan Garfield, chief technology evangelist for Codefresh, which develops a CI/CD platform, said that while much progress still need to be made in terms of spurring adoption of CI/CD platforms and best DevOps practices, the shift toward microservices-based applications inevitably will force the issue. The inherent complexity associated with building and maintaining applications consisting of hundreds of microservices based on containers, which regularly are ripped and replaced, will require all development teams to adopt a CI/CD platform. Right now, however, the shift to microservices is even less nascent than DevOps—21% of survey respondents said they are not employing cloud-native architectures because they are overwhelmed by the prospect.

Garfield said once organizations more aggressively embrace microservices to increase the rate at which applications are developed and deployed, Codefresh is betting most will opt to standardize on a CI/CD platform based on Kubernetes. Most organizations have come to realize they will be building and deploying applications across multiple clouds. A CI/CD platform based on Kubernetes, such as the one offered by Codefresh, enables organizations to consistently apply the same set of best DevOps practices, he said Garfield. As such, competition among vendors that provide CI/CD platforms based on Kubernetes is sure to be fierce in the months ahead.

In the meantime, a 10-year effort to convince organizations to employ best DevOps practices more broadly appears finally to be on the cusp of becoming mainstream. Organizations of all sizes have embraced DevOps unevenly. In fact, while most organizations have been able to achieve continuous integration with a handful of development teams, very few organizations are anywhere near close to achieving continuous delivery of application code within a production environment.

The shift to modern applications based on containers, however, will require most organizations to standardize on a set of best practices across the enterprise. Pressure to deliver applications faster in the age of digital business transformation is mounting with each passing day. The only unknown at this point is to what degree will organizations be able to automate those processes.

— Mike Vizard

May 20, 2019
Security: Are You Doing DevOps Right?

Phil Kernick, co-founder and CTO of cybersecurity specialist CQR Consulting, has no fundamental problem with DevOps, but asks, from a security perspective, “How many people do it right?”

If DevOps is going to work and produce secure systems, then developers must take responsibility for security. It’s not something that can be treated as an additional process.

But abstract responsibility isn’t sufficient. It’s rare for developers to have security tools in their kit and an understanding of their results, said Kernick.

Learn From History

As former systems administrator and past president of the Systems Administrators Guild of Australia (SAGE-AU, now the Information Technology Professionals Association), Kernick suggested that DevOps pretends that the discipline of systems administration does not exist and merely treats infrastructure as if it were a software library.

Spinning up an instance is easy, but do you know that it is properly designed and maintained? This is a real concern, given the number of people working as developers without professional training, Kernick explained.

Repeatable loops and short development cycles do make sense. But are you confident all the individual pieces being assembled were built properly?

That raises questions about the software supply chain. Where did that Docker container actually come from? Is it well-maintained?

The process needs to be managed, yet, people at some organizations are “just grabbing things from anywhere,” Kernick said.

“It almost integrates the ‘not my problem’ attitude with development,” he noted.

Developers tend to care about whether a component works from a functional perspective, but an untrustworthy piece of code will compile and run.

Developers working in a DevOps environment need to understand the tools that help ensure code is secure, and they need to understand infrastructure, said Kernick.

‘Code Reuse is Bug Reuse’

DevOps makes the old joke that “code reuse is bug reuse” even worse, said Kernick, citing the example of a piece of vulnerable code shared on the Stack Overflow site and reused more than 100,000 times in GitHub-resident projects.

“I don’t want DevOps running in my bank,” he said. What he does want is well-engineered, secure, well-run, certified software.

Sacrificing security might save some time and get a new product on the market sooner, which might be acceptable if there are no real risks to the user.

It is easy to tell if a system is really important, as it involves tradable value, safety or privacy. Obvious areas include banking and health. Similarly, it is clear that a website that allows access without requiring any credentials is unimportant.

But there’s a wide middle ground where it’s “really hard” to determine a system’s importance because it is so difficult to imagine how criminals might exploit it.

For example, Kernick once bought a DVD cataloging app to help avoid duplicating items already in his very extensive collection. He thought this fell into the “unimportant” category. But—fortunately, as it turned out—he took the usual precaution of using a unique password for the associated service. Sometime later, he received a sextortion email that proffered that password as supposed proof that the criminal had gained control of his computer.

Worryingly, when he told the developer what had happened, it did not accept that there was a problem. The company said the password quoted in the malicious email wasn’t his password for the service—proving in the process that it was storing passwords in plain text!—even though he explained he changed his password as soon as he received the message. Predictably, he uninstalled the app.

Clearly, Kernick didn’t know what development methodologies that company used, but that’s not the point. The anecdote shows that a seemingly unimportant system can quickly become important to the user in situations outside the developer’s control. Consequently, security is always important.

DevOps and Security

He suggests that as long as an organization has the right security and governance processes in place, it won’t matter what development methodologies are used. So it can safely adopt DevOps or whatever else is most efficient in the circumstances.

It is possible to use DevOps practices to achieve speed without sacrificing security, Kernick said. But to do that, organizations need to take advantage of advances in software development without throwing away hard-won security experience.

— Stephen Withers

May 20, 2019
Using Automation Tools to Drive Collaboration, Innovation

How automation can help business move past the walls of confusion between dev and ops

In the current state of things, businesses are leaning more than ever on the collective intelligence of their tech teams to drive innovation within their respective organizations. These teams are always comprised of developers and operations professionals. With the foray into automation and the desire for companies to do more with less, it has never been more critical that all individuals, regardless of team, come together to do amazing things. Of all of the services available, Chef is a great example of a suite of tools that want to empower teams to do just that: come together and innovate. It is all about bridging gaps, which can range from simply redefining how teams think about each other to more complex things such as knowledge gaps.

The first gap that almost always seems to come up when bringing teams together and driving business value is the duties gap. For too long we have sat on opposite sides of the coin. In operations in particular, too often we see ourselves as the ones that have to deal with the aftermath of unfortunate problems within code. But the fact is, we should all care about our systems, we should all care about our code and we should all be ensuring the longevity of both.

Once you’ve moved past the first hurdle, then comes the gap in knowledge. Scripting has become pretty common as companies press for automation, but in some instances, it becomes necessary to build up existing team members. Using enterprise automation tools such as Chef, entire teams and entire companies can begin caring about a shared thing: the configuration, health and state of their infrastructure and applications. In doing so, those same teams can begin speaking a shared language. Once this knowledge and shared language are in place, developers no longer view the ops team as an “other,” but rather as collaborators. They can each use their various areas of expertise and speak the same language without having actually having to speak the same language.

The third common gap is the process gap. Process can represent all of those past processes that a company is reluctant to let go of, which can hinder the ability of the developers and operations humans when they’re attempting to collaborate. The process gap can become particularly difficult to move past without leadership buy-in; as such, it is critical to involve business decision-makers in this transformation. While nearly the entire industry is beginning to move toward more collaborative environments, the entire leadership team must be onboard with the requirements to make changes happen. With the use of automation tools in particular, though, processes can begin to shift more toward collaboration-friendly policies and you can then make the case for further expansion with proof that it can aid in your transformation.

Empathy is the final gap that must be overcome. The great part about the other gaps is that they work hand in hand to solve each other’s problems. By promoting collaboration, resolving these gaps are also facilitating collaboration. The empathy gap is largely caused by silos of the past that have led to the commonly talked-about “wall of confusion.” Closing the knowledge and duties gap, developers and operations humans can now communicate and understand the same language and processes each is following. This allows the wall to be broken down and operations humans and developers alike can care about both code and stability.

It’s easy to start getting dev and ops teams working together and on a more even playing field once these gaps have been eradicated. This becomes a big driver for innovation and is, in many cases, a true recipe for success within the company. During my career, I’ve both watched and been involved in these transformations. Working with solutions such as Chef has allowed me to cross the bridge myself, and likewise, be able to share with others how that can be scaled out to entire organizations.

— Brittany Woods

May 17, 2019
The State of Low-Code Development

As enterprises continue to play catch-up when it comes to meeting their internal demand for new software services and applications, more enterprises—but still, only a minority—are turning to low-code development platforms to try to fill the gap.

Low-code development platform provider OutSystems released its sixth annual “State of Application Development Report.” The report is based on surveys conducted in March of 3,300 IT professionals.

The report found that a sizable minority (41%) of respondents are already using low-code platforms, while another 10% stated they were about to start using a low-code development platform. For comparison, in the 2018 report, 34% of respondents said they were using low-code development platforms and 9% said they were about to start using these platforms. Clearly, interest in these platforms is rising, if not modestly.

Low-code development platforms strive to make software development more accessible. They do so by removing traditional coding interfaces with graphical user interfaces. And they typically target development toward a specific functionality, whether that be web applications, business process automation, IoT and, quite often, databases. The low-code development platform market is expected to grow to $27.2 billion by 2022 from $4.3 billion in 2017, an annual growth rate of 44%.

The demand for software has never been higher. According to the OutSystems report, 64% of IT professionals said they have an application development backlog. For 19% of respondents, that backlog is deeper than 10 apps. While 50% said their backlogs have remained the same, 39% report that their app backlogs have improved over the past year.

The time to deliver web apps and mobile apps is mixed. The 2018 OutSystems report found that 54% of respondents took four months or less to deliver a web application. This year, 61% said it takes them four months or less to deliver a web application. Mobile app development has changed a little: 55% on average said they deliver apps in four months or less.

According to OutSystems, enterprises using low-code development platforms are 12% more likely to report that their backlogs have improved year over year.

Those findings echo similar surveys. For instance, a survey released earlier this month from low-code provider Appian found that nearly 80% of its respondents believe that using low-code can free developer time to work on higher-level projects. That survey also found 86% of IT developers agree that emerging technology is increasing the pressure on the IT organization.

One thing is certain, the demand for software isn’t going to let up anytime soon. According to the OutSystems report, the number of applications respondents plan to deliver this year is 60% higher than last year. For those with more than 500 employees, 65% said they had plans to deliver 10 or more apps, 38% plan to build 25 or more apps and 15% said they plan to develop 100 or more apps this year.

Despite the high demand for enterprise software, only 36% of organizations have larger development teams than they did a year ago. However, that’s likely not due for lack of trying to hire and retain development talent. The OutSystems survey found only 15% of respondents described developer recruitment as easy. “For many organizations, retention of developer talent appears to be an equally grave challenge,” according to the report.

With conditions like that, it’s only reasonable to expect low-code development platform popularity to continue to rise.

— George V. Hulme

May 16, 2019
Adobe Aims to Build Developer Ecosystem

Adobe today outlined an approach to building a developer ecosystem that revolves around open source code, application programming interfaces (APIs) and DevOps processes.

Matt Asay, head of developer ecosystem for Adobe, said in the last few years Adobe has increased its reliance on open source code to deliver offerings such as Adobe Experience Manager, a content management system that incorporates open source code for as much as 65% of its modules. In the course of that effort, the company has made reciprocal code contributions to a variety of open source projects being developed under the auspices of the Apache Software Foundation (ASF), including Apache Sling, a web development framework; Apache Oak, a content repository; Apache Felix, an implementation of a services gateway; and Apache Lucene, a text search engine.

Adobe also recently launched Adobe Experience Cloud, which relies on a variety of open source technologies to create a big data repository on top of which Adobe is encouraging developers to invoke APIs to build applications. Rather than build their own big data repositories, Adobe is making a case for relying on a multitenant big data platform it manages on behalf of customers.

Based on GitHub data, Adobe currently ranks as the 14th largest corporate open source contributor, up from No. 32 in 2017. One of the primary reasons Adobe was able to move up that list so quickly was its move to acquire Magento, an e-commerce platform based heavily on open source code. But now that the company has come to appreciate what can be accomplished by relying on open source code, organizations should expect to see Adobe accelerating the rate at which it will be making contributions to a wide variety of open source projects.

At the same time, Asay said, Adobe is making major investments in developing microservices that it plans to make it possible for developers to consume via its APIs. The Adobe Experience Cloud, for example, is a suite of software-as-a-service (SaaS) applications that employ a common data model deployed on a set of Kubernetes clusters running in the Microsoft Azure cloud.

Asay noted Adobe is trying to make it clear that it has a lot of empathy toward developers committed to open source code. Adobe is a provider of commercial software-as-a-service (SaaS) applications, but it wants to develop a developer ecosystem that consumes the data residing in those applications via its APIs. To foster the development of those applications, Adobe has already signaled it is willing to share best DevOps practices with organizations that commit to invoking those APIs.

Adobe is one of many providers of commercial software that are increasingly dependent on open source code. It will be interesting to see where the line between the desire to use open source projects to build applications and actual open source applications lies in the years ahead. But the one thing that is clear is that without DevOps processes and a well-defined set of APIs to guide them, there’s not much chance any vendor would be able to build a meaningful developer ecosystem of any size.

— Mike Vizard

May 15, 2019