devopsy.kinsta.cloud

Category: Blogs

The Secure Software Development Life Cycle: Syncing Development and Security
Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

The Changing Nature of Software Development

The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:
- The code is still fresh in the developers’ minds.
- Coding problems can be caught earlier and more easily while developers are still thinking about the code.
- It mitigates the risk of developers not remembering the code context at a later date.
Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

Automated Security Assurance and Out-of-Band Activities

When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

Life in the Fast Lane

For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.
May 13, 2020
Eclipse Foundation Moving to Brussels

The Eclipse Foundation announced today it will begin to transition its headquarters from Ottawa to Brussels as part of an effort to advance international expansion.

Mike Milinkovich, executive director of the Eclipse Foundation, said with so many open source organizations based in North America, there is a clear need for an open source organization to have a larger presence in Europe. As nearly half of the strategic members that provide funding to the Eclipse Foundation are based in Europe, it made sense for the Eclipse Foundation to take on that role.

The Eclipse Foundation is now home to 375 open source projects resulting in more than 240 million lines of code. Some of the most widely employed Eclipse Foundation projects include the Eclipse integrated development environment (IDE) and Jakarta, which is a follow-on to Java Enterprise Edition platform, previously owned by Oracle. In total, the Eclipse Foundation’s projects represent more than 13 billion Euros of investment.

In general, Milinkovich said contributions to open source projects have accelerated in the wake of the COVID-19 pandemic. Developers who are staying home to help combat the epidemic apparently have more time to contribute to projects. The expectation is by moving to Brussels, more European developers will contribute to projects involving technologies such as internet of things (IoT) initiatives that address industrial use cases, he added.

The Eclipse Foundation plans to establish a new legal entity sometime in July, with personnel relocating or added to a Brussels office over time depending on the nature of the Eclipse project being supported, Milinkovich said.

It’s not clear to what impact being headquartered in Europe will have on open source projects, which are by their very nature global. However, Milinkovich noted most of the recent live events hosted by the Eclipse Foundation have been held in Europe. It may be a while before anyone is attending an IT conference in person, but Milinkovich noted European developers already play a major role in the Eclipse Foundation projects.

Between the Eclipse Foundation, the Linux Foundation and the OpenStack Foundation, there is no shortage of opportunities for developers to contribute to open source projects. Many of those projects count on contributions from developers who work for IT vendors that have a vested interest in a specific project. In fact, many open source projects provide a way for IT vendors to defer the cost of creating a core piece of technology that doesn’t provide differentiated value. Rather than reinvent the wheel, it makes more economic sense to share open source code with potential rivals.

Of course, it’s then up to each IT team to decide whether to employ that open source code themselves versus relying on an IT vendor to provide a curated instance of it under a support contract. Regardless, the total cost of IT would be prohibitively higher right now if it were not for the proliferation of open source software. It’s also worth noting many IT vendors that build platforms on top of open source software would be considerably less profitable.

May 12, 2020
Getting Past Legacy Software Pains in Requirements Management

If you feel like you have outgrown your requirements management (RM) software, you are far from alone. From complex systems, such as IBM Doors, to document-based tracking through Microsoft Office, legacy RM tools are having a hard time catching up to the innovation occurring in highly-regulated industries. As we see the line between hardware and software become increasingly blurred, development methodologies are evolving faster than ever before. Sometimes, these changes happen day-to-day or even hour-to-hour, making project traceability feel impossible.

No matter how complex the software or notable the reputation, RM providers don’t always deliver a system that matches the goals of teams that need to quickly adapt, innovate and grow. This misalignment can create several pain points that interfere with productivity. While some can be attributed to shifts in the marketplace, others are directly rooted in the software tools you are using to meet compliance.

Here are some common snafus and how to work your way out of them.

Multiple Stakeholders, Multiple Problems

From avionics to automotive to medtech, highly-regulated industries see many different stakeholders and players, and that is a good thing. In order to reach peak public and functional safety, it’s crucial to value the input of multiple roles and skill sets. But, what happens if one or some of these folks don’t know how to use your RM software? At best it’s a shame that they can provide their two cents and at worst this begins a recipe for compliance disaster. To sidestep this conundrum, opt for a software that seamlessly flows with multiple roles. More so, make sure whatever software you choose integreates user-friendly traceability. It’s crucial that each and every individual on the project be able to see the progress made from beginning to end.

So, You Missed a Deadline…

It happens to the best of us. You were asked to provide feedback on a requirement and you missed your shot to chime in. Whether a colleague left a comment for you in a Word or Google Doc or shot over an email to glean your opinion, the mode of collaboration you have in place failed you. That’s right, this isn’t all your fault. Review processes are too complex these days and they require collaboration software that sets the intentions of the users clearly. This requires real-time editing and notifications to help keep you and your team on track. To prevent falling into this trap, look for an RM tool that prompts next steps and sends timely notifications with clear instructions. Conversations about “who dropped the ball” aren’t productive or fair, the RM software you integrate should fill this gap in human error.

You’ve Been Blocked

You are frantically trying to enter crucial data into the system but you are somehow locked out. You can’t get a hold of the person who manages access and you are beginning to feel frantic. This isn’t just frustrating for you, it also poses some substantial risks to the company. On top of losing a couple of hours trying to break into the system, this clunky process inevitably chips away at the desire to provide feedback with any regularity or confidence. This goes against the entire purpose of collecting data in the first place. To facilitate continuous growth and data collection, your RM tool should be open, accessible and intuitive. Only then will you encourage the kind of constant input and collaboration from stakeholders that is necessary to keep up with breakneck innovation.

When an Upgrade Spells Doom

Back in the day, we all used to get skittish when an iPhone software upgrade notification popped up on our screen. Will I lose all my photos and contacts? What about all those passwords I saved to log-in to my favorite apps? With the advent of the Cloud, much of this fear has dissipated. When it comes to your RM software, your team shouldn’t be afraid to upgrade the system to fix issues, improve security and access the latest features.

Yet, these systems are often so customized or patched-together that an upgrade could mean disaster. Because the products you are building change and improve over time, you should have a RM system that can adapt quickly. When it’s time to purchase legacy software, weigh the opportunity costs of investing in something so stale. Ultimately, is the pain of being locked-out or unsupported on various platforms worth the headache?

Pain points aside, we are living in an age that has bred the most disruptive and creative products to date. From ultra-fast and sleek electric cars to life-like prosthetics to self-piloted spaceships, we have some of the best and brightest minds toiling away on how to propel us into the future. At the same time, the regulatory environment has become even more stringent to meet both the demands of the marketplace and public safety. It is going to take synced and streamlined teams to decrease time-to-market and meet the ever-increasing demands of compliance. To pull this off, you need collaboration infrastructure in place that keeps your team organized and catches mistakes often missed by disconnected individuals.

May 12, 2020
Survey Surfaces Root Causes of DevSecOps Tension

Results of a survey published by SaltStack, a provider of IT automation tools, suggests tensions between cybersecurity and IT professionals on the one side and DevOps teams on the other are running high. According to the survey of 130 cybersecurity and IT leaders, 70% of respondents said their organization is sacrificing data security for faster innovation, with most cybersecurity and IT managers making a case for prioritizing data protection over innovation, speed to market and cost.

Alex Peay, senior vice president for product at SaltStack, said that while it’s unlikely cybersecurity and IT leaders will be able to slow down the pace of innovation within their organizations, the survey results make it clear IT organizations are struggling to keep pace.

On the plus side, the results also show that cybersecurity and IT operations teams are working more closely together. More than half—54%—of cybersecurity leaders said they communicate effectively with IT professionals, while 45% of IT professionals concurred.

Best DevSecOps processes are, of course, meant to bridge the divide between DevOps teams and the rest of the IT organization. The expectation is that by pushing more responsibility for cybersecurity to the left, the pressure on cybersecurity and IT teams would be reduced. However, DevSecOps adoption remains nascent at best—many DevOps teams still don’t have the tools required to implement security controls programmatically within their applications.

Even when they do have the tools needed to add security controls, organizations need to set up workflows that will enable cybersecurity teams to verify that those controls have been properly implemented. Given the chronic shortage of cybersecurity expertise, the rate at which applications are being deployed and updated easily overwhelms the amount of time cybersecurity teams have available to analyze modules of code that are now often updated several times a week. Most cybersecurity teams are already struggling to keep pace with patches for existing applications, let alone any new application modules.

Of course, there’s not a lot of love lost between developers and cybersecurity teams. DevOps teams generally blame cybersecurity teams for slowing down the rate at which applications are deployed. In fact, one of the primary reasons DevSecOps is gaining traction among developers is that it represents a way to remove cybersecurity professionals from the application development process.

Cybersecurity professionals, conversely, often view application developers as the root cause of the cybersecurity problem. Too many developers are reusing modules of code without first making sure those modules have been updated to address a known vulnerability. To add insult to injury, whenever a new vulnerability is discovered days, weeks or even months may go by before developers address it. To be fair, however, cybersecurity professionals are not especially adept at prioritizing vulnerabilities; as far as developers are concerned, the list of vulnerabilities presented is just one in a series of bugs that need to be addressed. Unless otherwise directed, developers will focus on bugs that impact features and performance before a potential security issue that has yet to manifest itself as an issue impacting end users.

In general, advances in DevSecOps are being made that should provide some much-needed relief to IT and cybersecurity professionals. It’s just slowing down the rate at which applications are deployed and updated might not be one of them.

May 7, 2020
Sacrificing Security for Speed: 5 Mistakes Businesses Make in Application Development

Earlier this year, the Democratic party in Iowa announced its plans to use a smartphone app to calculate and transmit their caucus results. Using technology to improve the speed of governance, one would think, “What could possibly go wrong? A lot, apparently. The app’s failure on results day was attributed to reporting and coding issues.

While security was the matter of concern from the day of its announcement, the inevitable happened. Data and security breaches happen almost every minute. University of Maryland researchers find cyberattacks every 39 seconds. The last decade has seen many data breaches, putting personal information of billions of users in the hands of dubious entities. Every enterprise, from Yahoo to Facebook and Target to Home Depot, has been under attack—and this is likely to continue. Research has found that cybersecurity breaches will result in over 146 billion records stolen by 2023.

Poor security is putting enterprises, governments and citizens at risk every day. Yet, in a hurry to leverage technology, companies bring unsecured applications to market all the time. In essence, they sacrifice security for speed. Adding to this, today’s modern web and mobile applications are built with latest and greatest technology stacks and frameworks, heavily reliant on client side functionality, and integration to multiclouds and third party systems using a myriad of APIs. Also teams are more diverse and work collaboratively using remote workforces.

These trends increase the security challenges the application development teams need to be aware of, and leverage platforms that provide built-in controls and protection against these to avoid security breaches and attacks.

While prioritizing speed over security in application development take into consideration the following mistakes that you need to avoid and address.

Not Looking at Data Security Holistically

Data tends to be the most important and valuable aspect of modern web applications. Poor application design and architecture leads to data and security breaches. Application development teams generally assume that by providing the right authentication and authorization measures to the application, data will be protected. This is a misconception. Right measures to provide data security involve focussing on data integrity, fine grained data access and encrypting data while in rest as well as in motion. In addition, data security needs to be looked at holistically from the time the request is made to the time response is sent back across all layers of the application runtime.

Not Considering Security Across the Application Development Lifecycle

Today’s modern web applications are highly sophisticated and built with a big focus on simplistic user experience combined with high scalability. This combination can be challenging for application development teams from a security perspective. Most development teams focus only on silos when securing the application (only client, server or integration layer). Teams should focus on end-to-end full stack security when developing applications. Also application teams should enforce security best practices incorporated by default as part of the collaborative development process.

Not Focusing on API Security

Most of the modern web applications use APIs from systems and services which include internal enterprise systems, cloud SaaS APIs, partner APIs and third party product APIs. Today, almost all web applications tend to expose their own functionality to the external environment as a core set of APIs. What’s more, nearly 100% of web applications today tend to expose its own functionality as a core set of APIs to the external world. Teams need to make sure they are using external APIs with proper security guidelines and protocols as well as exposing their own APIs with multiple choices of protecting them. API access needs to be protected with both coarse grained as well as fine grained measures.

Not Providing Strong Authorization and Authentication Methods

Authenticating your application and authorizing what users can access is an important part of application security. Without this, you are leaving your attack surface wide open. Your application needs to incorporate stringent and strong measures for authentication to prevent unauthorized access. This includes multi-factor authentication, passwordless authentication, single sign on and if using passwords very strong password policies. It must also offer fine grained role-based access control preventing access of sensitive and confidential data to non-privileged users. Moving to a market with ambiguous weak authentication, lack of fine grained control, improper session control and insufficient logging might not seem like a probable risk until you’re attacked.

Not Incorporating Vulnerability Testing Throughout the Development Lifecycle

Security threats are evolving faster than anyone can keep track of. The Open Web Application Security Project (OWASP), a community of application developers and security professionals, identifies the top 10 security risks each application team must mitigate. This includes risks across injection, data exposure, misconfiguration, security deserialization and so on. Development teams should incorporate vulnerability assessment as a continuous process and not leave it at the end of the deployment cycle.

Automating Security with Development Platforms

Integrating security into your application development process does not have to slow you down. By utilizing key technologies such as a low-code platform, you can accelerate development and enable security procedures at the same time.

While promising accelerated development, what an ideal low-code application development platform offers is a visual development environment and code-customization with two-way workplace sync with IDEs. It also enables autogeneration of code, ensures extensibility and reuse with prefabs, and allows for full integration with CI/CD pipelines.

One of the important features of a low-code platform is built-in security, one that ensures automation of the development of application-level security features. A perfect platform provides a configuration for prevention of security vulnerabilities such as XSS and CSRF and ensures in-built encryption, robust authentication and authorization systems, along with enterprise-grade auditability and traceability.

While speed may be the name of the game, rolling out your applications without considering security would have little positive impact if they fail to function and are not secure. One of the best ways to integrate security across your application development lifecycle is to leverage the benefits of low-code platforms that are designed for professional development, those that have built-in, application-level security features. While your application development plans may be time-critical, security cannot be an afterthought, because sacrificing security for speed may make it longer for you to mitigate the risks than achieve your application development goals.

May 7, 2020
DevOps as a Service: Migrating Your Entire DevOps Stack to the Cloud
DevOps as a Service (DaaS) enables teams to centralize their tooling and workflow into one unified solution. This solution typically contains all necessary DevOps pipeline features, which replace legacy tooling. This article explains how DaaS works, including pros and cons, and an example showing how to migrate from Azure DevOps Server to Azure DevOps in the cloud.

What Is DaaS?

DaaS is a managed, cloud-based service that provides a unified DevOps toolchain. All or most of the tools necessary for a continuous integration/continuous delivery (CI/CD) pipeline are collected in a single platform. This platform is then provided to teams with the support of dedicated DevOps professionals.

The goal of DaaS is to enable organizations to focus on developing and delivering software without having to worry about managing or maintaining tools. It is designed to abstract away the intricacies of tool integration, deployment and maintenance. This enables teams to focus on higher-level tasks, and outsources significant manual effort.

DaaS can provide small to medium businesses with enterprise-level infrastructure and tooling without needing to hire more staff or build extensive expertise. Instead, these businesses can rely on the experience of DaaS providers to create, deploy and optimize a pipeline for them. These pipelines are created to be intuitive and to facilitate the smooth collaboration of all team members.

DaaS Pros and Cons

If you are looking to migrate your development processes to the cloud, there are several migration strategies you can use. One involves moving existing tools to cloud resources as microservices, which you must then integrate. The other may involve scraping existing tools and adopting a DaaS. Whichever the case, you need to understand the pros and cons of DaaS before you can make the right choice for your organization.

Pros of DaaS:
- Managed services provide access to dedicated DevOps engineers for support, expertise and optimization.
- Provider teams have experience across a range of organizations and industries, and can customize solutions for you based on that experience.
- DaaS teams can provide mentorship and guidance which helps your team improve their own skills. This enables teams to learn from the mistakes of others and prevents repeating mistakes.
Cons of DaaS:
- The importance of pipeline management and availability requires you to partner with a service provider that is reliable and can ensure zero to minimal interruptions.
- Outsourcing infrastructure demands and providing access to source code and other sensitive data and systems. This can create a security risk that you are not in control of.
- DevOps teams still need to understand the tools being implemented and the basics of how to manage and use those tools.
- Managed services often cost more than self-implemented pipelines and the costs may not be offset by an in-house reduction in IT responsibilities.
DevOps Cloud Migration Example: Migrating from Azure DevOps Server to Azure DevOps in the Cloud

Azure DevOps Server, formerly called Team Foundation Server (TFS), is a server hosted on-premises that enables you to build DevOps pipelines. While based on similar services to those offered in the Azure cloud, it requires you to manage and maintain your infrastructure and provides limited support for your configurations.

By migrating to the cloud, you can outsource many of your infrastructure responsibilities, focusing instead on producing quality software. Azure DevOps Services are an example of partially managed DaaS that you can use.

Below is a brief guide for how to transfer your data and projects from DevOps Server. This guide is adapted from the full DaaS guide provided by Microsoft.
1. Preparation: Planning your migration requires taking an inventory of how you are currently using your tools, what data you need to migrate and how migration will impact your productivity. You also need to determine if you need additional licenses. For this step and those to follow, there is a tool you can use to assist you in the process.
2. Configure Your Prerequisites: Before you can migrate your pipeline data you need to set-up a few prerequisites. You should synchronize your local Active Directory (AD) with Azure AD for authentication. You also need to set up security and compliance measures to ensure that your infrastructure remains secure.
3. Update and Validate Your Server: Check to make sure that your server is up-to-date with the latest version of Azure DevOps Server. If you are still using TFS, this may mean a series of updates. Once you’re fully updated, you can use the migrator tool to validate the collection databases of each of your projects. If any errors are found, you need to fix those issues during this phase.
4. Ready Your Cloud Resources: After all errors are eliminated, you can begin preparing your cloud resources for import. This requires assigning, activating and mapping your DevOps Services subscriptions. You also need to generate a template for your import settings through the migrator tool. These settings should be saved in your Import Specification file. Finally, you need to create a container instance in the data center you want to use your DevOps Services in.
5. Migrate Your Pipelines: After all of your preparatory and planning stages are done, you are ready to migrate your workloads. During this phase, you should first run a test import to ensure that all configurations are correct and that the import process goes smoothly with no data corruption. This helps ensure that you don’t create unnecessary downtime.
Provided your test run goes smoothly, you can then proceed to import your data. Once uploaded, you need to assign your organization name, set up billing and redirect your on-premises build servers to the new cloud resources. After you are done, you can resume operations and begin operating your pipelines directly from the cloud.

Conclusion

DaaS is typically not just a centralized platform, but also a managed service that comes with certain levels of support and optimization. If you are short on DevOps talent and tooling, DaaS can fill this gap or even help you and your team learn DevOps skills.

However, since you are giving the DaaS of your choice control over your pipeline, you need to investigate and research. You will be giving your DaaS access to source code and security. Before signing a contract, make sure this service is trustworthy and meets your standards.
May 5, 2020
Need for Increased Training — Strained Budgets Strain Enterprise IT Teams

As enterprises have increasingly embraced cloud, hybrid IT environments and DevOps methodologies, many of the old siloes associated with IT departments have crumbled—while demand for training and skills that reflect new technology requirements have risen considerably.

This new reality was reflected in the findings of a new survey from IT management software provider SolarWinds, and was published in the SolarWinds IT Trends Report 2020. While the survey was conducted prior to the novel coronavirus pandemic, the results highlight the challenging environment IT departments faced as they headed into the current economic and operations challenges.

The survey found that the top three ways enterprise technology professional roles are changing include the need to retrain existing staff (43%), increased on-premises responsibilities (40%) and increased work week hours (37%). Concurrently, those IT professionals surveyed cited lack of budget and resources (36%), unclear or shifting priorities (23%) and lack of training for personnel (12%).

That lack of training is a challenge that is getting worse, as 48% of respondents stated that new technology professionals entering the workforce aren’t coming equipped with the skills necessary to manage modern, distributed IT environments. Only 28% of those asked believe that these new workers do come with the skills necessary.

Non-technical, or so-called soft skills, that enable cross-functional teams, are seen increasingly critical to success. These skills include project management (69%), interpersonal communication (57%) and people management (53%). Interestingly, only 53% of those surveyed said they are comfortable communicating with their business leaders when it comes to requesting new technology purchases, investing time/budget into team training and related requests.

These findings are echoed in the recent DevOps Institute Upskilling 2020: Enterprise DevOps Skills Report. Based on 1,300 respondents, this survey found more than 50% of enterprises are challenged managing the people and the processes that make DevOps possible. Most respondents (61%) also said interpersonal skills are crucial.

Other areas where the SolarWinds survey found skills to be essential include application performance management (APM), security and compliance. According to the survey, 54% of those surveyed report spending more time managing applications and services over infrastructure and hardware. And, the survey found, when organizations move to cloud technologies, 57% use network traffic analysis and network application analysis, while 55% said they use user experience monitoring. Finally, 52% said they use log analysis. Sixty-one percent said for APM, 61% said they use both native management tools provided by their cloud vendor and third-party toolsets.

The survey also found that as businesses increase in size, the more IT turns to log analytics (58% for enterprise), and tracing (24% for enterprise) increases. While only 23% of small businesses have not or don’t plan to adopt technology to gain visibility into cloud or SaaS technologies.

The survey also found that 65% of IT professionals spend at least 10% of their day on security management. The top skills they have prioritized to develop within their organizations include network security (48%), security and event management (33%), and backup and recovery (29%).

Additionally, regulatory compliance has fueled the need for increased staff, according to 46% of respondents, with the biggest impact coming from GDPR (45%), PCI DSS (34%) and HIPAA (34%).

The SolarWinds IT Trends Report 2020 was conducted in December 2019, and is based on responses from 227 technology practitioners, managers and directors from public-and private small, mid-size and enterprise businesses within the U.S. and Canada.

May 4, 2020
How to Manage Data in Hybrid Cloud Environments

We’ve long-since established that multi-generational, multi-cloud environments are the new norm. But, how does one go about managing data in those environments?

In this post, we’ll take a look at the ramifications of this hybrid cloud reality and best practices for managing your data for increased scalability and heightened availability.

It’s All Cloud

Whether it’s Amazon Web Services (AWS), Google Cloud or Microsoft Azure (or some combination thereof), cloud is all the rage, with a hybrid approach gaining momentum with 81% of cloud users working with two or more providers (according to a recent Gartner study). Not only does this strategy take companies out of the business of hosting their own applications, but it also leads to benefits such as avoiding vendor lock-in, reduced costs and optimized performance.

Benefits to Mixing Cloud and On-Prem Environments

Mixing cloud and on-prem environments means you can pick and choose where your workloads and data live—it’s really an optimization. For example, if your application is CPU intensive, you can run it on the cloud provider that gives you the most CPU for your dollar. Similarly, if your data workload requires significant storage, you can go to the cloud provider that offers the best bang for your buck on storage.

Businesses should look at their application and database and then use the cloud provider that offers the best of class for that workload. A mixed cloud also gives you the ability to always have a low-cost secondary site recovery plan in place—you’re always ready to spin up on another cloud provider if you need to.

Managing Data: The Challenges of Hybrid Cloud

The benefits of multi-cloud are many, but when it comes to managing your data, things can get tricky. Not only do you have multiple cloud providers to balance, you also have to consider data stored on-premises and how that data is accessed from the cloud.

You also have to consider data replication between clouds. If you’re not doing a full mirror of your data between each cloud, it’s critical you remain acutely aware of what data lives where. You’ll want to consider creating extensive documentation and diagrams of what data lives in which cloud. If you are replicating data between clouds, you also have to justify the additional operating and engineering cost to accomplish your goal.

How to Manage Data in Hybrid Cloud Environments

Fortunately, there are several libraries providing abstractions for cloud services, such as object stores. Leveraging abstractions within your applications allows you to move more freely between cloud providers.

Companies should strongly consider storing their data in a consistent manner within each cloud, leveraging the same technologies to reduce the sprawl, maintenance and expertise required to operate those technologies. For example, use a relational database that all the cloud vendors provide—for data updated and changed frequently, it should live in the scope of the local cloud provider to reduce latency and network costs, because traffic within the cloud provider is generally free. If you were to write to a database outside the cloud provider, it’d cost more and be considerably slower.

The leaders in the cloud provider space offer a fairly secure environment for storing sensitive data, as long as you’re following good practices and using your own source of encryption. However, it all comes down to your individual environment. For some organizations, there will be workloads that should remain on-premises—for instance, highly sensitive data for which regulations require on-premises storage.

If data has to be stored and encrypted on-premises, many cloud providers offer a secure means of connecting your cloud environments to your on-premises environment for access to sensitive information, such as providing secure VPN connectivity to virtual private clouds.

Multi-cloud might not be for everyone; you have to weigh the benefits with the costs, especially as those factors relate to your individual organization. While there are pitfalls, the practices and tooling to effectively manage your data in hybrid cloud environments are all out there. Because so many of us are choosing to run our workloads on multiple clouds, collectively we’ve overcome many of the aforementioned challenges and can take advantage of all the benefits hybrid cloud provides.

May 4, 2020
Communicating with Management About Technical Debt
We’re all familiar with the challenges of technical debt. While it’s often unavoidable–due to time constraints, resource considerations or simply a lack of good information–it still weighs on our minds and puts us on the defensive. It makes future changes that much more difficult. As it builds up, it generates that nagging sense of an unpaid bill that’s accumulated interest and is about to come due.

But, perhaps, the most challenging aspect of technical debt is simply this: getting senior business leaders to understand what it is and convincing them to do something about it.

There are many reasons we’re not getting through. Management is often under significant pressure to deliver results with little patience for discussing anything that doesn’t directly contribute to a specific outcome. Resources may be limited. It’s simply human nature to prefer short-term gratification–developing a new customer-facing app, for example–to the longer-term but behind-the-scenes benefit of paying down technical debt.

If we’re honest, we also bear some responsibility for our lack of progress. We need to do a better job of clearly defining and explaining why technical debt should matter to business leaders. But, how do we do this?

Here are five ways to explain and highlight the importance of addressing technical debt to key decision makers.

Drop the Tech Talk

When discussing technical debt, it’s easy to fall back on shop talk–i.e., explaining technical debt in IT terms. This is a battle that must be waged in business terms. Fortunately, there are many parallels between technical and financial debt that business leaders are familiar with.

All healthy businesses carry financial debt on their books, and leaders know that debt must be kept within certain limits in order to maintain a healthy balance sheet. Indeed, they are acutely aware of the consequences of carrying too much debt. Not only does it endanger the company’s credit rating–making future borrowing more expensive–but it also accumulates interest and may force companies to curtail certain actions, such as paying dividends or buying back stock, that are important to shareholders. That’s why, when debt levels rise to a certain point, most companies bite the bullet and make a concerted effort to pay down debt before embarking on another business-building cycle.

Outline the Potential Business Impact for Carrying too Much Technical Debt

Technical debt must be kept within certain limits to avoid hurting the business. Unpaid technical debt generates interest that increases over time and adds to the cost of fixing the problem. Carrying too much technical debt leads to negative business (versus IT) consequences, including:
- Lost sales and/or lower productivity due to system outages.
- A loss of competitive advantage due to a progressively poorer user experience.
- An inability to adapt to market changes.
- Fines due to security breaches.
- Poor decisions resulting from inconsistent or untimely data.
Find Creative and Visual Ways to Tell the Story

There are several different ways you can contextualize technical debt–from using everyday analogies, such as the importance of daily household upkeep, to the benefits of preventative maintenance, as in the classic Fram oil filter “pay me now or pay me later” commercials. You can also leverage compelling visuals like the one below to dramatize your arguments.

Source: Projectmanagement.com

Rinse and Repeat

In making your case to business leaders on the need to address technical debt, it’s important to adopt a campaign approach. Think like advertisers who measure their impact in terms of reach and frequency–how many people they reach and how many times those people are exposed to their message. While you’re not running an advertising campaign, you need to be prepared to make your case over time, and to reach both the decision makers and the people who influence the decision makers. One email, or one presentation to management, isn’t going to get your message across.

Creating a Healthy IT Balance Sheet

Technical debt is inevitable and, in some cases, makes sound business sense–i.e., when speed-to-market is critical, when resources are limited or information is incomplete. If technical debt reaches a certain level, it makes good business sense to forego immediate gratification projects (developing that shiny new app) in order to pay it down.

That’s why framing technical debt in a manner that business leaders understand (i.e, through the lens of financial debt) can make business leaders more inclined to realize the importance of managing it, as they do other risks facing the business.

Of course, responsible IT leaders not only surface issues that require management attention, they also offer potential solutions. For example, funding strategies to pay down technical debt, including ongoing efforts and small and large improvement projects.

By treating technical debt as a business rather than a technical issue, technology officers stand a better chance of breaking through with management, paying down those nagging old debts and finally getting their IT balance sheets in order.
May 1, 2020
Deploying OpenStack: Pick a Distribution With These 7 Qualities

OpenStack, which turns 10 years old in July, remains the leading open source infrastructure component in private clouds. But, there is a plethora of OpenStack distributions out there, and selecting the right one is vital to the success of every organization’s OpenStack project.

How do you know which is best? It’s an important question because, despite OpenStack’s popularity, companies often face serious challenges when adopting and deploying it. Put simply, OpenStack can be time-consuming and skill-heavy in order to deploy it, unless the chosen distribution is equipped to overcome those challenges.

Thus, anyone planning to deploy OpenStack should make sure the distribution they pick meets the following seven criteria.

Strong Economics

Cloud environments are supposed to be more cost-efficient than proprietary hardware. That’s why enterprises love the cloud, after all. Therefore, the number one priority when choosing an OpenStack distribution is to make sure it can indeed reduce costs. That means steering clear of OpenStack platforms that are hard to deploy, maintain, upgrade and force you to struggle with basic operations. It’s also important that the distribution’s pricing model be clear and predictable so that organizations can plan expenses accurately.

Totally Open Source

While OpenStack itself is open source, the installers provided by the vendors as part of their distributions often are not. This can lead to additional costs being applied to the licenses and situations where organizations are forced to pay for the distribution before even trying it out. Furthermore, all types of environments in use—including staging and development—need to be covered by the license, too. These pitfalls are sidestepped with OpenStack distributions that are 100% open source, providing better economics and flexibility for organizations.

Predictable Release Cadence

While the release cadence of OpenStack is predictable and well documented, not all distributions follow the upstream quickly enough. Making sure the OpenStack distribution you choose supports the latest stable upstream release as soon as possible is crucial for a few reasons. The upstream release may have features that are important for the organization. Or there may be bug fixes that they feel are critical. Picking a downstream distribution with a predictable release cadence that stays in sync with the upstream ensures transparency and allows organizations to plan the upgrade process.

Long Support Runway

Support services are essential for OpenStack production environments, especially when service level agreements (SLAs) apply. But, how long vendors will support older versions of OpenStack can vary. Though there is always an option to upgrade or re-deploy, there are times when it may be beneficial for organizations to stay with the current version. Thus, how long the vendor will provide support services is a key factor in choosing a distribution.

Upgrades Made Easy

There inevitably comes a time for most organizations when they want to upgrade their upstream OpenStack. However, OpenStack upgrades are known to be complex, and many commercial distributions do not support them. Even if they do, the process is complex and must be executed manually. Thus, choosing an OpenStack distribution that provides support for fully automated upgrades is essential for the success of the cloud operations team.

Simplified Operations

Even after an OpenStack cloud is deployed, consideration must be given to the ongoing operations that can become complex and fragile. Maintaining the cloud on a daily basis includes operations such as scaling the cluster out or recovering it from failure. While most OpenStack distributions don’t provide mechanisms to simplify these tasks—forcing users to execute them manually—some do. Organizations should look to distributions that do a good job automating complex operational tasks, saving time and money.

Flexible Technology Choices

OpenStack is a flexible cloud platform, supporting various hypervisors, software-defined networking (SDN) solutions and storage plugins. But many distributions are tied to a single stack. That means an organization may need to re-platform or move to a heterogeneous environment in the future. Avoid that trap by selecting a distribution that can adapt to work with new technologies.

By looking for these seven qualities, organizations can get the most out of their OpenStack distribution and optimize the cloud infrastructure on which they increasingly rely.

April 27, 2020