devopsy.kinsta.cloud

Tag: developers

Blockchains Done Right Are the Next Evolution in Open Source

Open source code is more than just a way to create new technology. It’s a disruptive force that changed the way software is built, from taking individual developers and turning them into thriving communities to changing how enterprises do business–building open ecosystems versus restricted walled-gardens.

The next evolution of this movement is blockchain technology. Decentralized groups of developers across the globe are contributing to greater data integrity for businesses, better guarantees to ecosystem partners and can work together on live instances including their data. And that was the missing piece–live instances. Up until now, we could only collaborate on writing the code for a system together. Today, with blockchain technology, we can also collaborate on running this system together.

Open Source is Decentralized

From its ideological beginnings in the 1980s, open source code changed how we do business around the world, all stemming from developers’ work in software creation. Developers have seen open source disrupting almost every field of infrastructure, from operating systems (Linux in the cloud) to databases (MySQL, MongoDB, Redis) to programming languages (JavaScript, Python, Java, C, PHP).

Over time, open source connected thousands of developers and established a corporate precedent. In parallel, the largest corporations in the world are also the biggest contributors to open source. It is with these two transformations open source is now over 50% of all code relied upon in the average proprietary system in enterprise.

Now, blockchain is disrupting existing business models by extending the implementations and possibilities of open software. It does so by providing a transparent and immutable record keeping method, auditability of algorithms, forking of live instances with the data and possibility facilitate governance participation, all derived from an open source, decentralized community.

Amazon recently added support for open source blockchain frameworks such as Hyperledger and Ethereum on AWS. This is a great first step toward making this technology widely available. As more AWS blockchain customers build on the open source frameworks to build for enterprise business, the powerful capabilities of open source will become a part of the blockchain movement. Transparency, auditability and forkability in code, all present enormous opportunities for developers while also demonstrating a precedent.

It should be noted where these instances run, whether on private permissioned networks or public permissionless ones, is material to their ability to provide external guarantees to their users. The highest standard of trust is permissionless–where any member of the public can participate in their operation and audit.

Decentralization Rewards Both Developers and Enterprise Business

Businesses have gained major advantages through the use of open source software. In the same way, decentralized blockchain infrastructure offers businesses increased security, robustness and most importantly, guaranteed transparency with its customers.

Prior to the open source software movement, traditional methods of programming were expensive, slow to develop and lacked insight into user experience until long after each new release came to market. Today, developer communities download, interact and actively contribute to blockchain projects in the same way as open source. Decentralized developers give businesses rapid ability to replace arbitrary features with intentional decision-making by a large, merit-based community. Decentralized blockchains are Open Source 2.0.

Today, most standard apps run with centralized back ends. The server hosts the back end and dictates how the database evolves, given users’ requests and transactions. End users interact through the front end and never see what’s going on behind their static experience. What if we gave users a way to shift the power structure inherent in this state? Apps could become better for their users and much more competitive.

Not All Blockchains Fit the Open Source Credo

There’s a wide spectrum in the industry with blockchain technologies ranging from fully public to completely private. There’s a lively debate whether the value given by these fundamentally different solutions is comparable. I argue that distributed ledger technologies or private blockchains have little technological innovation. Their validators are permissioned, which means they cannot provide unbiased external guarantees to their partners and users.

That said, there are some benefits to using private blockchains in certain use-cases such as coordination between a small number of competitors or WalMart onboarding all its external supply-chain services onto one coordinated platform, but they are limited in giving any guarantees to anyone not participating in the consensus (i.e. not running a node).

Public blockchains offer a business greater transparency, because there are neutral and external parties operating the blockchain outside of the company and its customers with an independent incentive system. This removes anyone’s opportunity inside the company to falsify records, as they could potentially do on a private blockchain, or have data integrity relying on business relationships and dependency. Public blockchains also live up to the ultimate test of trust–from the comfort of your home you can verify by yourself every guarantee provided by the network.

Where Hybrid Blockchain Comes In

Most public blockchains were designed for absolute decentralization, which makes them impractical for mainstream businesses. Private blockchains are highly practical but don’t offer the transparency and trust possible with public blockchains.

Hybrid blockchains, such as the one developed by Orbs, offer the best of both worlds. They’re perfectly designed to address fundamental issues with performance and interoperability while allowing for applications in highly distributed environments. They provide strong guarantees, verifiable by anyone, yet leave businesses in control of their business models, governance and security.

— Tal Kol

July 19, 2019
Low-Code Has Taken Development by Storm. Why Not the Web?
For more than a decade, development tools increasingly have made their way into the hands of less-technical people. On the web in particular, we’ve eliminated the webmaster as the middleman with content management systems and moved progressively toward a model where non-technical users could assemble their own sites with little to no coding experience of their own.

Fast forward and today, the terms “no-code” and “low-code” are used to describe this idea. Furthermore, no-code and low-code tools have been on a decade-long rise, with an increasing impact on the web. Examples include:
- WYSIWYG site-builders, such as Wix and Squarespace
- WordPress Gutenberg
- Drupal’s new Layout Builder
While this has been a strong, decade-long market trend, we’re only at the beginning. This trend won’t stop until new website experiences are automatically generated and optimized by machine learning.

Trends Driving the Low-Code and No-Code Movements

According to Wave, “In our survey of global developers, 23% reported using low-code platforms in 2018, and another 22% planned to do so within a year.”

Major market forces driving this trend include a talent shortage among developers, with an estimated 1 million computer programming jobs expected to remain unfilled by 2020 in the U.S. alone. What’s more, the developers who are employed are often overloaded with work and struggle with how to prioritize it all. Some of this burden could be removed by low-code and no-code tools, allowing marketers and other non-technical professionals to do some of the development work themselves. In addition, the fact that technology has permeated every aspect of our lives, from our smartphones to our smart homes, has driven the need for more people to become creators.

“As creating things on the internet becomes more accessible, more people will become makers. It’s no longer limited to the <1% of engineers that can code, resulting in an explosion of ideas from all kinds of people,” said Ryan Hoover, founder of Product Hunt, in a blog post.

In other words, the supply of web creators must keep up with the demand for more digital experiences across more channels.

But this does not only apply to individuals. Consider this: The typical large organization has to build and maintain hundreds of sites. These organizations need to build, launch and customize sites in days or weeks, not months. Today and in the future, marketers and other non-technical stakeholders can embrace no-code and low-code tools to develop websites rapidly.

Abstraction Drives Innovation

As predicted in my middleman blog post, developers won’t go away. Just as the role of the original webmaster has evolved with the advent of the CMS, the role of web developers is changing with the rise of low-code and no-code tools.

Today, developers tend to focus on creating next-generation digital experiences that require new and emerging technologies not yet available in no-code solutions. In the process, they help invent and build new technologies such as React, Vue.js, etc.

Successful no-code approaches abstract away complexity for web development. This enables less-technical people to do things that previously only could be done by developers. When those abstractions happen, developers can move on to the next area of innovation.

Such abstractions are a good thing for both developers and non-technical website creators. When everyone is a builder, more good things will happen on the web. I was excited about this trend more than 12 years ago and remain excited today. I’m eager to see the progress no-code and low-code solutions will bring to the digital world in the next decade.

— Dries Buytaret
July 18, 2019
Networking: The DevOps Community Deserves Better

Developers of cloud-native applications are at the heart of a process of radical transformation shaking up the business world. Using DevOps and SRE methodologies, modern development teams are bringing a level of agility to the game that is all about freeing enterprises from the shackles of the old, pre-cloud days and letting them take advantage of new opportunities at light speed.

But the developer community has a problem. The process of developing and delivering cloud-native applications in a DevOps paradigm demands the right connectivity to back it up, and traditional networks aren’t doing the job. Cloud-native developers need cloud-native networking—network solutions that work in the same frictionless and agile way they do—solutions that put the application first and replace traditional manual network configuration with connectivity-as-code.

To play their part, developers need application-friendly connectivity that is designed for applications composed of microservices and APIs which span many edges, clouds and service meshes. A new software only, cloud-native approach to connectivity is required to address this and other challenges such as security, performance and operational support at scale.

There are four things developers shouldn’t take for granted in a network solution: agility, security, simplicity and performance.

Agility

What application developers need is a cloud-native, agile, on-demand alternative to traditional networking—something that delivers the speed to market that they need, and safeguards their profitability. With a model such as application-specific networking in network-as-a-service models, application development teams can create on-demand connectivity across edge, cloud and service mesh environments to support their apps wherever their apps travel.

Security

App developers require zero-trust software defined perimeter security that meets and exceeds even the most stringent compliance standards, and can be controlled as code by their DevOps tools and applications.

Simplicity

New networking approaches that puts the application in contol can abstract the developer and DevOps teams from the complexity of differences between underlying networks, clouds or service meshes.

Cost-Effective Performance

Application-controlled network-as-a-service models can deliver operational cost reduction over traditional MPLS and VPN solutions, while boosting throughput and performance compared with legacy alternatives.

Conclusion

Developers deserve better networking. It’s time for them to say goodbye to the old way of doing things and move on from restrictive legacy solutions with their lack of scalability, absence of agility, poor security and unpredictable overheads.

— Galeal Zino

July 17, 2019
GitLab Survey Surfaces Major DevSecOps Challenges Ahead

A report based on a survey of 4,071 software professionals published this week by GitLab, a provider of a continuous integration and continuous deployment (CI/CD) platform, found that while appreciation of the potential value of DevSecOps best practices is high, the ability to implement those practices is uneven at best.

According to the survey, half of the respondents reported that security vulnerabilities are discovered mostly by the security team rather than developers after code is merged and in a test environment. And, when cybersecurity professionals participate in a DevSecOps process, the survey found those organizations are three times more likely to discover bugs before code is merged. In addition, a full 90% of those organizations are more likely to have tested between 91% and 100% of their code early in the development process.

Obviously, that’s better than discovering them after they’ve been deployed in a production environment. On the downside, however, nearly half of security professionals participating in the GitLab survey (49%) said they struggle to get developers to make remediation of vulnerabilities a priority. That challenge may reflect the overall maturity of the DevSecOps practices in place. For example, only 25% of developers participating in the survey rated their security practices as being good. That compares to only 20% of security professionals who rated their processes as good. Only 14% of respondents said they are relying on application security tools to test more than 91% of their code. A full 44% are using these types of tools to test less than a third of their code.

Priyanka Sharma, director of technology evangelism for GitLab, said the survey makes it clear that DevSecOps is now officially a thing in the enterprise. However, only 44% of the survey respondents said that security vulnerabilities are a performance metric for developers in their organizations. As such, it’s clear there is still a long way to go before anything approaching DevSecOps nirvana is likely to be achieved. In fact, Sharma noted building and deploying more secure applications may require organizations to slow down the rate at which applications are being built, at least initially.

The GitLab survey makes it clear most organizations are still struggling with mastering DevOps. Only 28% of developers said they feel good about their organization’s level of DevOps sophistication, while less than half (45%) said they have been able to implement continuous code deployment at least somewhere in their organization. That level of adoption suggests there still is plenty of opportunity to refine DevOps processes that are not fully ingrained. In fact, it appears most organizations are still trying to master agile development methodologies—more than half of the respondents said they employ Scrum (54%) as their application development methodology, followed by Kanban at 37% and DevOps at 36%.

Ultimately, most organizations will have no choice when it comes to embracing DevSecOps. There simply are not enough cybersecurity professionals available to secure every application on their own. That means developers will need to assume more responsibility for cybersecurity, regardless of whether they like it. DevSecOps processes will be required to validate whether developers have implemented all the security patches and controls required. Anything less than that going forward will be deemed as nothing short of reckless—which, as any lawyer will gladly share, means much higher penalties for everyone involved.

— Mike Vizard

July 17, 2019
DevOps Is Killing the ITOps Engineer (and That’s Bad)

In theory, DevOps is about bridging the gap between developers and ITOps teams. In practice, however, DevOps often can feel as though its real goal is to turn ITOps engineers into developers, without really requiring developers to dive head-first into ITOps work.

In this article, we’ll explain why DevOps gives more glory to development work than to ITOps, and how that poses a problem to the DevOps world as a whole.

In DevOps, Developers Come First

We live in a world that fetishizes code and the creation of code. Developers fetch among the highest salaries in IT. The work they do is sometimes compared to magic. There are a litany of boot camps designed to teach people to code. From Silicon Valley to The Social Network, coders are depicted in popular media as whiz kids who are building a fantastical world the rest of us can’t even imagine until the coders hand it to us.

By comparison, ITOps engineers—people whose main job is to deploy and manage software, not write it—get much less glory. I’ve yet to hear of an ITOps boot camp. Generally speaking, ITOps employees get paid much less than developers; some ITOps workers, such as those who do help desk work, barely make minimal wage. And no one makes movies where an ITOps engineer saves the world by rebooting a crashed server or applying the latest security patches.

This trend is problematic, of course, because the work performed by ITOps is equally critical as development work for sustaining our digital world. Without ITOps teams, all of the code developers get paid so much to write would be useless because there would be no one to put it into production and keep it running when it’s there.

There are many possible explanations for our tendency to celebrate programmers much more than the people who manage the software programmers build. The most important reason, I think, is we live in a world where creators of all types are generally held in greater esteem than maintainers. That’s true in a variety of fields, from building science (where architects who design structures are held in much higher regard than, say, the roofers and painters who maintain them) to the automotive industry (the white-collared engineers who designed your car are probably paid a lot more than the grit-streaked mechanic who changes your oil). The IT industry is not special in this regard.

DevOps as Euphemism for ‘Everyone Should Program’

The fetishization of programming would probably happen even if DevOps didn’t exist. But sometimes, I think DevOps is exacerbating the tendency to deny ITOps teams their fair share of prestige.

Beneath the surface of many conversations about DevOps culture and continuous delivery is the idea that if only ITOps engineers knew more about how to write code and discuss code with developers, their organizations would be better positioned to deliver software more quickly while also improving quality.

In my experience, it’s much rarer to find DevOps advocates interested in pushing developers to play a more hands-on role in ITOps work. Almost no one goes around saying, “If only developers spent more time provisioning infrastructure, software delivery would be more efficient.” And when they do, they are accused of trying to kill the developer by requiring programmers to participate in maintenance-related tasks below their pay grade.

I’d therefore suggest one of the challenges DevOps faces today is not killing developers, but killing ITOps engineers and further devaluing the work they do. To keep advancing DevOps, we need to pursue greater parity between developers and ITOps teams within DevOps culture.

— Chris Tozzi

July 12, 2019
A Golden Age for Developers

There’s probably never been a time since the dawn of programming when there has been more opportunity for developers—individuals and teams—to imagine, create and be successful. Developers are able to do a lot more (and do things a lot faster) with more tools, a better development ecosystem and a tighter connection with the rest of the enterprise than was possible even a few years ago.

To me, we are in a golden age for developers. And it comes just as the need for developers has never been greater, in every enterprise.

Three things have come together to create this moment: Culture, code and the cloud.

Changing Culture

First, developers today operate in a culture that is far more collaborative than in years past, both internally and externally. A big part of that is the growing adoption of the DevOps methodology, which breaks down silos between business units, IT and development through partnerships between developers and the enterprise. It’s changing how we work and think.

DevOps leads to a process of continuous integration of new ideas and features that meet business needs, and continuous deployment life cycles that get those features operational rapidly. Rather than taking weeks or months to get a new version of an application up and running, it’s possible to make constant incremental changes and have things running in days or even hours. The enterprise is able to be exceptionally agile responding to business changes and challenges—and, if there’s a problem or failure, the mean time to recovery is just as fast.

Democratized Code, Empowering Cloud

A major factor in enabling this approach is the widespread use of open source code. Open source has democratized access to powerful tools and platforms that can greatly accelerate work for any developer. Open source projects are mature, stable and growing, which provides equal access for citizen and enterprise developers alike. The size of your IT operation no longer matters: Developers everywhere can call up on their laptops the same tools that once were available only to web-scale unicorns. It removes limits to a developer’s imagination and the ability to create something new.

Finally, the ever-expanding realm of cloud-native computing is putting incredible resources and computing ability within reach of every developer. Tools such as Kubernetes, which let you create and orchestrate applications in containers that can then be deployed and run in the cloud; serverless technologies; and other new ways of using distributed computing power remove barriers. Where a developer once might have been reluctant to create apps that required high levels of computing power, that’s not the case now with the cloud. What once may have taken access to a Cray supercomputer is now at a developer’s fingertips.

Retraining, Not Replacement

If there’s any challenge in this golden age, it’s helping the enterprise to make the transition—in particular, facilitating the leap that existing development teams must take in using these new approaches and new tools. In fact, the top issue for cloud developers is to make this cultural change.

That takes both strong top-down leadership and an openness by veteran developers to new ways of working for developers, especially those who’ve been around for a while.

Too often, we see companies trying to make the switch by offering early retirement to their veteran developers and trying to recruit a new team that’s already used to DevOps, open source and the cloud. That’s the wrong way to do it. Instead, even as they bring in newer developers, companies should look to retrain their existing team.

That takes more than just telling people, “Here are the new ways we’re going to operate,” and then throwing them into it. There are a lot of tools and gateways available that can help people move gradually from the tools and languages they have been using. For example, in the last 12 months alone, numerous open source Kubernetes operators, service brokers and frameworks have been introduced that allow enterprise teams to leverage cloud-native technology from a context they already know, including WebLogic, database and Java. Look for combinations of people and projects that are likely to result in some early wins, and then have those people help train the rest of the organization.

Make sure to take advantage, too, of the external collaborative environment that exists. Have veterans go to conferences or meet-ups and learn from the community—which, thanks to open source, is huge and growing.

This will do more than give you a development team that’s built for today’s market, which demands that you deploy faster and react to failures in a more graceful way. It also will help you recruit and retain. Developers are twice as likely to recommend their workplace to if they are using DevOps principles—they are happier, easier to recruit and easier to retain.

In this golden age for developers, the potentials are limitless—and every enterprise can participate. Making that cultural change, taking advantage of open source code and exploiting the power in the cloud—those are the keys to building the team and the applications that will spell success.

— Bob Quillin

June 26, 2019
Developers Have More in Common With Marketers Than They Think
Marketing professionals and developers together are critical in advancing customer experience

More than a decade ago, in the early age of digital transformation, industry analysts and insiders began discussing the need for an increased focus on the collaboration between CTOs, CIOs and CMOs to achieve business goals. It was determined that CMOs would spend more on technology than their technical c-suite counterparts, thus creating an increased need for cross-functional alignment and cooperation.

Today, we find the same kind of alignment is still required, but on an even deeper technical level—between developers and marketers. They are charged with the day-to-day operations of highly scaled and complex marketing operations driven by increasingly complex martech stacks. Companies across industries and markets are becoming more digitally oriented, so the need for seamless collaboration between business functions is mission-critical.

There are many reasons for the perception that marketers and developers share completely different business priorities—from the trope of left brain versus right brain to completely different modes of operation, it has been assumed that marketers are practitioners of soft science and developers are entrenched in code. However, when you consider the nature of today’s modern marketing technology, you realize that both skill sets and sets of expertise are crucial to engaging, retaining and growing a company’s customer base.

To marketers, developers can come across as unapproachable or highly focused internally on technical tasks that distance them from customers. To developers, marketers may seem less technically savvy and unsympathetic to the time requirements in technical projects and the juggling act and trade-offs that ensue for competing priorities. The result is an environment and dynamic in which one party often can feel the other has more control and say over the other. However, what we’re learning is that most of these sentiments are exaggerated or are changing as the business landscape continues to evolve. The truth is, marketers and developers have a lot more in common than they think.

A recent survey of 500 marketers and developers at companies of all sizes uncovered the real truth behind this relationship and understand its inner workings. We looked at identifying their priorities, challenges and where they see success when it comes to their working relationship. Two things in particular stood out:
1. Business alignment is overwhelmingly the key objective that both parties agree they need to effectively achieve to succeed.
2. Customer experience is by far the highest priority where the two overlap.
Broken down, 79% of marketers and 83% of developers agree that being aligned on business goals and priorities is a huge factor in being able to succeed in their roles. Developers cultivate this partnership in large part by recognizing that the work of marketers is becoming more data-driven and technical—a fact that 73% of marketers report being true.

Meanwhile, customer success serves as the factor bringing marketing and DevOps closer together. Customer experience represents a critical driver to the success of any business, and on that, both marketers and developers passionately agree. Somewhat surprising, more developers (89%) than marketers (86%) agree with the notion that every touchpoint and interaction with a customer resolutely matters.

The area where marketers and developers face their greatest disconnect is time. Forty-three percent of marketers feel they cannot get requests done promptly, while an overwhelming majority of developers (86%) are confident in their ability to deliver work within a requested time frame. When it comes to the development of new products or software, this is the biggest pain point for both, leaving each side equally frustrated when trying to appease the demands of the other. But with strategic marketing efforts, better collaboration and a more innate understanding of each others’ roles, marketers and developers can drive powerful business results.

Here are just a few simple tips that can foster a more harmonious relationship between marketers and developers that results in real business value:
- Marketers should involve developers in software evaluations as early as possible.
- Developers should communicate the work required to accomplish a given request and any trade-offs that need to be made to curb marketers’ expectations.
- Both parties should reconnect outside of specific projects to frequently share context about their goals, challenges and opportunities.
That last tip is key, as the survey results show marketers and developers are more aligned on those factors than they realize. As the role of marketers continues to evolve in digital organizations and developers take note of this shifting tide, the two have the potential to wade each other through this massive wave of digital disruption. All it takes is walking a mile in each others’ shoes and realizing that both pairs fit.

— Len Shneyder
June 19, 2019
4 Things Developers Should Know About Security in the Age of DevSecOps

If you’re a developer, most of your experience when it comes to security probably centers on designing and writing secure code. You know how to prevent buffer overflows, architect your microservices in a way that helps mitigate the impact of a breach and otherwise churn out secure application code.

But the fact is that today, knowing how to keep the application itself secure is not enough—even if you are a developer. We’re living in the age of DevSecOps, and developers everywhere are being asked to play broader roles in security at all stages of the application delivery pipeline, from code implementation through to production release and management.

With that reality in mind, here’s a look at four things developers should know about security today.

What is DevSecOps, and What Does It Mean for Developers?

Before diving into four critical things for developers to know in the age of DevSecOps, let’s take a look at what DevSecOps means.

You’ve probably heard of DevOps, an approach to software delivery that emphasizes constant collaboration between developers and IT teams.

DevSecOps extends that concept by adding security to the equation. For organizations that have embraced DevSecOps, the entire software delivery team becomes responsible for helping to secure the application. Security is no longer the exclusive domain of security engineers.

In practice, DevSecOps includes work such as integrating vulnerability scanning into the build process using tools such as Packer and ensuring that images used for deployments meet GSO guidelines. Applying OWASP’s “Security by Design” principles is also a good best practice.

What that means for developers (to put it simply) is that being a security-minded developer means more than just writing secure code. Developers must now understand security challenges and best practices at all stages of the software delivery pipeline, starting with the design and implementation of code—developers’ traditional domain—and continuing through with testing, staging, deployment and post-release management—all of which traditionally were not areas in which developers played much of a role.

This isn’t to say that developers now have to bear primary responsibility for all of the things that happen after code is written. They don’t. Their main job is still to write code. But developers should have a solid understanding of the security implications of everything that happens once they hand off code to other members of the software delivery team, to ensure they are doing their best to write code that will stay secure as it travels down the pipeline.

DevSecOps Security Lessons for Developers

If you’re a developer, the DevSecOps trend means you should now have some expertise in the following:

Microservices Security is Difficult (and Developers Can Make it a Little Easier)

Microservices architectures, which have become very common because of the agility they provide to applications, create extra security challenges that were not present in monolithic architectures. The main reason why is that microservices add many more moving pieces to an application. As a result, there are more potential security vulnerabilities within the application, and detecting those vulnerabilities can be more difficult because there is more activity to monitor.

Developers can help to address this challenge, and one way is to think about security monitoring complexity when they are deciding how many microservices to create. If developers can reduce the total number of microservices in an application without sacrificing agility, they can simplify security monitoring and enable a more secure application overall.

Developers also can make sure the microservices they write log security-related information sufficiently and clearly. You don’t want to make it more difficult for your colleagues who are monitoring an application to keep track of security events because the application doesn’t log authentication information in sufficient detail, for example.

You Can No Longer Count on Firewalls

In the days when most software ran on-premises, firewalls were a handy way of isolating applications from most security threats.

Today, organizations face a string of cloud security challenges that didn’t exist when firewalls were designed. Firewalls can still be helpful in some circumstances, but in many cases, you can no longer neatly segment applications or services off from the public internet, because you need the internet for services that are spread across a hybrid infrastructure to communicate with each other.

For developers, the lesson here is that it’s especially critical to design and write code that can resist threats that originate from the internet. Even if you don’t expect a particular part of the application to be exposed to the public internet, assume it might be, either because deployment patterns change in the future or the component is exposed without anyone realizing it.

To put this another way: Developers can’t and shouldn’t expect the IT team to be able to erect firewalls that will keep applications secure. More of the burden has shifted to developers to write applications that can resist network-based security threats because the IT team can no longer deploy firewalls like it used to.

Shift Security Testing Left

DevSecOps goes hand in hand with the mantra of shift-left testing. The latter term refers to the practice of performing tests earlier in the software delivery pipeline, rather than waiting until just before deployment to do the tests.

Shift-left testing can apply to any type of software testing, including security tests. For developers, taking advantage of shift-left security testing is a useful way of identifying security flaws within newly written code early, when they can be fixed with less effort because they have not yet been integrated into the broader application code base.

Security testing at later stages of the delivery pipeline is important, too, especially because you won’t be able to detect all security flaws until you can monitor all of your microservices as they interact with each other. But the time developers have to spend rewriting code to address security issues will be reduced greatly if their organization takes advantage of shift-left security testing.

Don’t Be Afraid to Ask for Compliance Help

A final point worth mentioning relates to compliance. Compliance is becoming ever-more challenging. And so is creating applications that meet the security requirements of compliance frameworks.

In the past, developers were often left on their own to figure out how to address compliance needs. Given the spirit of collaboration that DevOps and DevSecOps champion, however, developers should no longer feel like they have to go at it alone when it comes to interpreting and addressing compliance requirements. And indeed, they shouldn’t. If you are a coding expert, you’re probably not an expert in figuring out what complex compliance frameworks require.

The point here is that developers should not be afraid to ask for help—from legal experts, management or the IT team (which is more likely to have some experience with the compliance issues that arise once the software is in production) to make sure that the applications they design and write meet compliance requirements.

Conclusion

The developers’ main job is still writing code. But by having a greater awareness of the types of security risks that can arise within the code as it is pushed down the delivery chain, developers can do much to improve the security of the applications they write. They might even save themselves some time and headaches by reducing the number of complicated security issues they end up having to address by rewriting code.

This sponsored article was written on behalf of Symantec.

— Chris Tozzi

June 18, 2019
Pulumi Advances DevOps on AWS

Pulumi announced the availability of Pulumi Crosswalk for Amazon Web Services (AWS), an open source framework for deploying applications on Amazon Web Services (AWS).

Company CEO Joe Duffy said Pulumi Crosswalk for AWS provides a software-as-a-service (SaaS) application through which DevOps teams can automate the deployment of applications on AWS infrastructure using software development kits (SDKs) from Pulumi. The SDKs are based on programming tools such as JavaScript, Python, TypeScript and Go, which most developers already know how to use. That approach eliminates the need for DevOps teams to learn how to employ YAML files or to acquire tools such as CloudFormation or Terraform to deploy applications on AWS, he said.

Pulumi Crosswalk for AWS also embeds the best DevOps processes recommended by AWS directly within its SaaS tools, including patterns for containers and serverless computing frameworks, Duffy noted.

Pulumi Crosswalk for AWS is available on GitHub. It is designed to be integrated with existing Team and Enterprise Editions of Crosswalk that come with support and training provided by Pulumi.

In addition to AWS, Pulumi Crosswalk supports other cloud platforms, including Microsoft Azure and Google Cloud Platform (GCP). The company also plans to provide support for private clouds and leverage Kubernetes clusters to automate deployments across hybrid cloud computing environments.

Duffy noted that despite all the enthusiasm for DevOps, many IT operations teams have been left behind. While much time and effort has been put into unifying backend cloud services, the operational experience in the cloud still revolves around low-level application programming interfaces (APIs) or specialized tools that are challenging for IT operations teams to employ. That situation often creates a backlog of applications for IT operations to deploy. Crosswalk enables IT operations teams to leverage the skills developers have to deploy applications they approve on AWS, he said.

As cloud computing evolves in the age of DevOps, the relationship between developers and the IT operations team is becoming more nuanced. IT operations teams still need to put guardrails in place, but they can’t afford to be perceived as a bottleneck slowing down the rate at which applications can be deployed in the cloud. The challenge IT operations teams must overcome is finding a way to enable developers to self-service their application deployment requirements as much as possible within a set of policy guidelines defined by the internal IT team. That approach will enable developers and IT operations teams to get out of each other’s way.

It may be a while before IT operations and developers find the right DevOps balance that best suits their organizations. Individual teams within enterprises tend to define their own best practices based on the expertise available within the team. Ideally, those best practices are then shared and implemented as appropriate across the rest of the enterprise.

In the meantime, it will be interesting to see how aggressively cloud service providers embrace tools such as those from Pulumi. Cloud service providers have a vested interest in getting as many workloads deployed in their clouds as quickly as possible. They tend to be a little less enthusiastic about anything that makes it easier to move those workloads anytime a DevOps team sees fit.

— Mike Vizard

June 12, 2019
Scalability in the Age of DevOps: A Must for Success

DevOps seems to be an emerging topic “du jour” in the world of software development. And like it or not, it is showing no signs of slowing down. If used correctly, DevOps can be helpful—from making teams (developers and testers) work seamlessly to automating routine tasks, DevOps has proved its awesomeness in just a few years. So what is helping make DevOps a huge success? Scalability!

Technically speaking, scalability is something that defines the exact capability of the system, and it has to increase frequently to accommodate the ever-changing needs of the world. As customers rely more heavily on your services, achieving hyper-scale is becoming more crucial. To ensure scalability, you may need to redesign or rethink, your different processes and systems.

Say, for instance, customer demand seems to have reached its apex. Preparing comprehensive strategies that focus on scalability has become prime importance.

To get the most out of your application, invest in DevOps-related time and dollars. With the introduction of the cloud, developers are focusing on building features and products while ops (operations) are making sure everything stays in sync. At the same time, many traditional ops functions have been outsourced to cloud providers.

Scaling DevOps

Here are some best practices that can assist you in creating scalable, secure and high-performance deployments.

Be Vigilant

With the increase in the adoption of visualization, networks are more complex and heterogeneous, and so are the security risks associated with them. The only way left to manage these networks is by automating key management functions. Here is when DevOps comes into play. But for that, the method must be included with security as a key component, or the volume and pace of network would eventually change—several technologies such as SDN and virtualization will skyrocket the level of IT risk like never before. Another challenge is that security is still considered as an afterthought. And so-called business inhibitors are seen advising an organization on what can’t be done instead of how to do things securely. This is an area where security, developers and operation teams must foster a level of trust, or collaboration won’t exist. The only way to do this is incrementally and with vigilance.

Watch Changes Carefully

Considering DevOps as a collaborative mindset enforces professionals to come up with faster and more efficient ways to deploy, operate and upgrade applications. When new releases are delivered, several tools can ensure consistent configuration of infrastructure and software components. These tools also can be used to remediate security concerns by constantly validating the proper application of security’s best practices and taking automatic countermeasures.

Ease of Use

Automation and repetitiveness are what DevOps is all about. Fortunately, there are a few tools that are capable of automating the building and configuration of VMs. However, make sure you have the adequate horsepower to run this capability, either in-house—which is trickier to scale dynamically—or in the cloud, if your product is amenable to that. At the end of the day, it’s all about how you make your product installation and configuration easy.

Managing Gateways

While building any new goal or coming up with the best culture between development and operation teams, keep certain gates between functions to ensure that the production environment remains stable. Try to structure it in such a way that operations include development discussions and daily scrums. By doing this, operations teams simultaneously will understand what changes will be made in future releases. By integrating automation in both testing and operations, you will be able to find issues before they reach production. In addition, you’ll realize cost efficiencies and better quality operations.

Conclusion

In today’s fast-paced development environment, a well-thought preparation strategy for mass scalability is a must to make the entire process smooth and easy. DevOps reduces lead-up anxiety by getting a head start on planning, so you have more time to enjoy the fruits of your labor. Adding scalability in your strategy enables you to experiment and try new things without fearing failure. Testing new approaches ahead of time to see what does or doesn’t work will only help you learn and make your scalability efforts that much more effective for the future, as your company continues down the path of hyper-growth and hyper-scale.

— Herman Morgan

June 12, 2019