devopsy.kinsta.cloud

Tag: developers

How to Overcome Resistance to DevOps Implementation
The number of businesses adopting DevOps to make software releases happen faster without compromising on software quality continues to grow. Within the next five years, the DevOps market is expected to reach almost $13 billion. If you are among those who’ve decided to make a shift to DevOps, you are likely to experience resistance coming from the departments involved in a software development life cycle (SDLC), and even from end users, at the start of your DevOps journey.

In this article, we will outline the reasons why your employees may resist the DevOps approach and show how to overcome their resistance.

About DevOps Approach Implementation

Among the benefits DevOps brings are the fast provision of new infrastructure, quick and reliable delivery of software updates, fewer post-release errors due to the implementation of continuous testing and the alignment of testing and production environments, etc. DevOps implementation requires efforts in establishing tight collaboration between the development, QA and operations teams, as well as adopting new tools and methodologies, such as containerization, IT infrastructure automation, continuous integration and continuous delivery (CI/CD) tools.

A new approach calls for project managers, developers, infrastructure management, QA and operations teams to leave their comfort zones and get used to new working conditions. However, each stakeholder has reasons to resist DevOps implementation and requires a tailored approach to overcome them.

The Resistance of Project Managers

Why They May Resist

Project managers (PMs) are the first to face the changes when the DevOps approach comes into force. Their resistance originates from a range of new duties, new responsibility and knowledge they need to add to their playbook, such as:
- Persuading development, QA and operations teams involved in SDLC in the DevOps necessity.
- Establishing constant collaboration between developers, the QA team and the operations team.
- Getting familiar with DevOps-specific tools and techniques (CI/CD, continuous monitoring, version control tools, etc.) as well as cloud computing technologies like AWS, Azure, Google Cloud Provider (GCP).
How to Overcome Resistance

PMs should become DevOps evangelists as they will be the ones who will contribute the most to overcome the resistance of other parties involved. A CIO should provide a PM with sufficient training on all DevOps-related aspects. Such training should include the management of the development, the QA team and the operations team in the context of close collaboration between them. It should also provide the PM with the understanding of DevOps methodologies and tools–containerization, infrastructure as code (IaC), continuous integration and continuous delivery (CI/CD), cloud technologies, etc.

The Resistance of Developers

Why They May Resist

Developers may resist DevOps adoption due to the following reasons:
- They are not excited by the necessity to work with infrastructure engineers closer and deal with operational issues if the operations team is not competent enough to address them on their own.
- They are comfortable with the technology stack they’ve chosen for a particular project and not accustomed to caring about how familiar the other project team members are with these tools and technologies.
How to Overcome Resistance

PMs should embrace their soft skills to establish a mutual understanding between developers and infrastructure engineers. They should also make sure infrastructure engineers can work with the tools and technologies developers may use within the DevOps approach, e.g., Docker, Jenkins, by providing them with relevant training.

The Resistance of a QA Team

Why They May Resist

A QA team may feel concerned about a faster SDLC DevOps implementation, since it entails less time for testing. Test engineers now need to acquire new skills prescribed by automation across the entire SDLC. In particular, they face the need to learn new tools for automated testing (Selenium, Appium, fMBT) and API testing (JMeter, Postman).

How to Overcome Resistance

To make QA engineers less risk-averse, QA managers in cooperation with PMs, should provide them with appropriate training (tools for automated testing and API testing) and show the advantages DevOps may bring. An opportunity to increase test engineers’ qualification level, less effort on testing activities than required with manual testing are among such benefits.

The Resistance of an Infrastructure Department Manager

Why They May Resist

In the pre-DevOps times, an infrastructure department manager was responsible for controlling the design, configuration and delivery of infrastructure for development, testing and production. With DevOps on board and the IaC approach implemented, the infrastructure manager may feel as if they lose control over the IT infrastructure provisioning and management. What’s more, the scope of the infrastructure manager’s responsibilities extends greatly since they’ll need to run the infrastructure department as a competency center.

How to Overcome Resistance

A company’s CIO should explain the infrastructure manager their new responsibilities upfront. The infrastructure manager should stay assured that they change the area of control, not lose it. Within DevOps, the infrastructure department manager has to transform their approach to work. They must be able to help a PM correctly arrange the development, QA and operations team for each particular project taking into account project complexity and size. The infrastructure manager must be able to proactively deal with the cases when the team members involved in software development lack qualification for a project, and not wait until the lack in teams’ competencies results in the project prolongation, for example.

The Resistance of Operations Engineers

Why They May Resist

With DevOps in place, the operations team will have to coordinate their efforts with developers and the QA team from the very beginning of the project, as well as regularly report to the PM on the tasks completed, which is not the usual work approach. To be able to work in the DevOps environment, operations engineers will also have to get familiar with a range of IT automation, version control and other tools. What’s more, the operations staff’s responsibilities will now include the provision of the information on the IT infrastructure functioning to business and technical stakeholders.

How to Overcome Resistance

To help an operations team adapt to the DevOps culture, the infrastructure department manager should deliver training to make operations engineers familiar with new tools and technologies they will need to use, e.g., version control systems (Git, Team Foundation Server), software deployment automation tools (Chef, Puppet), etc. A PM, in their turn, will need their soft skills to increase the operations team’s willingness to work in close alignment with development and QA teams.

The Resistance of End Users

Why They May Resist

It may sound surprising, but even the primary beneficiaries of the DevOps approach implementation may resist the changes DevOps brings. There are two reasons for it:
- The time available for software acceptance testing gets reduced due to a faster SDLC.
- Acceptance testing becomes automated, and end users hardly trust automated tests.
How to Overcome Resistance

To dispel end users’ DevOps-related doubts, PMs must do their best to earn their trust by establishing strong communication with end users. If, for example, end users know software testing covers critical software functionality and the probability of post-release errors is minimized, their confidence in software reliability and the overall trust in the DevOps approach rises.

In a Nutshell

Each party involved in software development has its reasons to be suspicious when the DevOps approach is coming on board. New duties, close collaboration, the necessity to apply new tools and other DevOps-related changes may make project managers, developers, QA engineers, IT infrastructure managers, an operations team and even end users resist the new approach.

To overcome the resistance, a company’s CIO should maintain open communication with each party involved in SDLC, explain their new duties and listen to their concerns. It’s essential to make sure each team member realizes what changes and advantages DevOps brings into SDLC. To ensure they have the necessary knowledge and skills, appropriate training should be provided to project managers, developers, QA team, IT infrastructure manager and the operations team.

— Andrei Lipnitski
September 16, 2019
Better Together: Why Software-Development Toolmakers Should Embrace Integration

It’s getting harder for businesses that are building technology tools to get attention, traction and ultimately widespread adoption. You can’t just launch an amazing new developer tool and hope developers will find you; providers need to zero in on a specific use case that empowers developers while also ensuring those developers will still have access to the broad ecosystem of other tools they need to do their jobs.

The more forward-thinking companies in enterprise SaaS, public cloud computing and artificial intelligence are increasingly partnering with companies they might once have considered competitors to elevate the presence of all their brands among end users. By meeting in the middle, and integrating with a common-ground platform, providers join their customers where they are, on the platform that makes the most sense for them.

Instead of forcing customers to choose, providers can take advantage of powerful network effects, where their tools become more valuable because they’re part of a network. It’s one of the oldest concepts in computing: Metcalfe’s Law states the value of a network is equal to the square of the number of users on that network.

But building that network yourself can be time-consuming and costly, as many of those who’ve done it alone have discovered. That construction project can easily distract providers from their own core competencies, forcing them to spend time and resources on essential but undifferentiated development work.

Network Effects

The mobile side of tech has been operating under these principles since the launch of distribution platforms such as the App Store and Google Play, which introduced mobile developers to millions of potential customers. Those customers want seamless connections between their favorite apps and services to streamline their digital lives. They don’t want every app developer to create their own marketplace with incompatible payment methods, unfamiliar interfaces or strange hoops to jump through.

The explosion of enterprise software vendors enabled by cloud computing and software-as-a-service models has created similar patterns. Cloud-native developers have embraced distribution channels such as the AWS Marketplace as the best way to find their customers, and enterprise companies such as Box and Dropbox are making integrations with rival products and office productivity tools (like G Suite or Office 365) an important part of their product strategies.

“What seemed unfathomable merely a decade ago is now becoming commonplace as Fortune 500 companies are mixing and matching best-in-class technologies—from upstarts to cloud mainstays like Salesforce, Workday and ServiceNow—to power their business,” said Aaron Levie, Box CEO.

But the work required to enable those integrations is substantial.

Growing companies focused on building best-in-class tools for developers don’t always have the in-house expertise required to strike partnership deals with platforms and support customers with a world-class billing system. Likewise, end users often need to do their own due diligence when considering whether or not a promising new development tool will play nicely with their existing tech infrastructure.

Go to Market

Marketplaces are the best way to solve these problems. Service providers need distribution and integration with other development tools to reach end users, and end users want the peace of mind of knowing they’ll be able to properly evaluate a tool under consideration through a certified clearinghouse.

Companies can certainly build API-level integrations on their own for one-off partnerships or integrations where performance isn’t a major requirement. However, when performance is vital, such as with databases or infrastructure monitoring tools, a more deft touch is required.

These seamless, low-latency connections are only going to become more important in a multi-cloud world as companies use the power and scale of Kubernetes to build tech infrastructure that spans several different cloud providers and perhaps even their own on-premises servers. True service interoperability will require common frameworks to make sense of all those connections and allow developers to mix and match their favorite tools to create the technology stacks of the future.

Enterprise software silos are a thing of the past. The future of software development will rely on tools that blend the best available services—no matter where they were born—and link developers, service providers and platform companies in flexible and dependable ways.

The companies that figure out how to integrate best-of-breed software development tools with the leading platforms and services of our time will win. If you’re just starting out, let someone else handle the complexities of integration and distribution while you focus on creating the best developer tool you can.

— Jevon MacDonald

September 12, 2019
5 Tips to Eliminate Knowledge Gaps in Dev and QA
To create and release high-quality software, the software development lifecycle (SDLC) was established using different roles and processes designed to work seamlessly together. This approach is of critical importance because it spans the initial planning phase, all the way through production release and monitoring.

Roles vary within projects but typically include designers, business analysts (BA), developers, testers, scrum masters, project managers, product owners (PO) and technical architects (TA). Each one brings different expertise and skills to a project but ultimately, they are meant to collaborate and determine how to implement different aspects of the software.

The amount of processes can also vary for projects based on team size, release schedules, availability of resources and the complexity of the software.

What is the Knowledge Gap?

Without a distinction of responsibilities or a roadmap that identifies who owns each task in the SDLC, everyone assumes someone else will complete the tasks. The result is that the majority of these important steps remain incomplete or undone.

The reason this happens is because a knowledge gap exists among the team. This is especially true when teams are a mix of entry-, mid- and expert-level individuals. Sometimes, assumptions are made regarding the skill set, experience and domain knowledge that each individual brings to the project. Knowledge gaps can also develop at a more granular level, with teams using the same tools but in different ways. As an example, developers and testers might be using a single testing platform quite differently.

As teams begin collaboration on features for the software, they may encounter the following situations:
- Each team member has a different interpretation of the project requirements
- Developers assume testers have their same level of technical expertise
- A lack of ownership and assigned responsibilities among the team
- A PO has a feature idea and each team member has different ideas for how that feature should work
- The TA explains how a feature should be implemented using technical jargon that designers, POs, BAs and testers don’t understand
- A tester is not allowed appropriate time to complete testing due to tight release schedules
Identifying Knowledge Gaps

Knowledge gaps not only negatively impact the release of high quality software, but also team morale, productivity, job satisfaction and empowerment. The first step to finding acceptable solutions is to identify exactly where a knowledge gap exists. Some questions to help teams do this include:
- What are the common problems that occur in each phase of the SDLC?
- What processes are in place during the requirements, design, development, testing, acceptance and release phases of the SDLC?
- How effective is the communication between different roles in the team?
- Are the responsibilities of each team member clearly identified?
- How visible is the status of the project at any given time?
- How often are release cycles pushed to accommodate for more development and testing?
- Are the teams aware of what kind of customers are going to use the product?
- Is the velocity of the team stable? How often does it fluctuate and by how much?
Bridging Knowledge Gaps

Finding gaps in a team’s knowledge is the first step. The next step is determining how to narrow the divide. The following key factors help bridge the knowledge gap in teams:

Training

Sufficient training and tools should be provided to help teams do their jobs better. Proper training has a domino effect on the success of the project. It helps designers understand how to design mockups so developers can effectively implement the feature; testers can attend code reviews without intimidation and use tools more effectively; developers will understand why the testability of a feature is important and understand which tools can aid the development testing effort; the scrum master can better manage project tasks; the project managers can ensure the team collaborates to meet release schedules and deadlines; and finally, stakeholders can have an overview of the project through reports that are generated using various tools.

Visibility

For teams to work seamlessly together, we need to ensure the results of everyone’s efforts are visible to the entire team. It is important to understand how each contribution maps to the overall goals of the project. To increase visibility, teams can consider using the following:
1. Checklists: a list of items to be completed during each phase of the SDLC. If the items in the list are marked as done, then there is no ambiguity about which tasks need attention.
2. Visual Dashboards: give a high-level overview of the project’s health and status. These can be created on whiteboards, easel boards or in software and during daily meetings, teams can address the dashboard to ensure everyone, including business stakeholders, are aware of the high-level project status.
Clear Definition of Roles and Responsibilities

Each person needs to understand his/her role on the team, as well as the tasks they must accomplish on a daily, weekly, monthly or quarterly basis. Goals, objectives and expectations for each team member should be defined and discussed with respective peers and/or managers. This eliminates confusion and increases productivity and task completion.

Empowerment

In an age where individuals are increasingly more technical and skilled, what they still lack in their job functions is empowerment and autonomy. Contrary to the conventional wisdom that a project needs a single leader, the leadership responsibility can be effectively divided within each role on the team. Having one point of contact each from the design, development and testing teams means each can help to lead their respective sub-teams and help to ensure everyone within the project is working toward the same goals and objectives. By operating within this structure, the whole team becomes empowered.

Experimentation

Once sprints are completed and knowledge gaps have been identified, the whole team should come together to discuss solutions to existing problems. Based on this discussion, the team can start experimenting with different solutions to determine what works well or doesn’t. This constant experimentation and feedback loop helps to make the team more creative and empowers them to come up with solutions that work for their organization.

In summary, the knowledge gap has been a major obstacle for development teams in reaching their fullest potential. By identifying and reducing these gaps, teams can be more efficient and achieve faster release cycles with higher quality software.

— Raj Subramanian
August 23, 2019
OverOps Integrates AI Code Analyzer With CI/CD Platforms

At the DevOps World | Jenkins World 2019 conference, OverOps announced it has integrated its namesake tools for analyzing Java and Microsoft .NET code at runtime with a variety of continuous integration/continuous deployment (CI/CD) platforms, including Jenkins, JetBrains TeamCity, Atlassian Bamboo and Pivotal Concourse.

Eric Mizell, vice president of solution engineering for OverOps, noted that the more errors that are discovered by DevOps teams early in the development cycle, the less technical debt organizations must address after an application is deployed in a production environment. By pushing testing to further to the left of the application development process, the less troubleshooting will be required later on, he said.

OverOps employs predictive analytics and machine learning algorithms to identify new, increasing, resurfaced and critical errors in a release. It then generates a code quality report that ranks all severe issues likely to impact end users and application functions. By integrating OverOps within the CI/CD pipeline, DevOps teams can use those reports to determine whether code is safe to promote or automatically block unstable releases from moving forward.

In addition, because the machine learning algorithms surface the true root cause of an issue, DevOps teams can more efficiently remediate issues by routing code back to the development team responsible for all the issues that are being created downstream.

Making testing an integral part of the CI/CD process not only tightens the relationship between developers and testers, but also in many cases enables developers to test their own code before submitting it for review.

Mizell said the need to shift testing to the left has become more critical as customer tolerance for application errors is low, especially in use cases involving mobile applications—consumers are especially unlikely to give a mobile application a second chance after they’ve encountered an issue.

In an ideal world, of course, testing tools that make use of machine learning algorithms would be employed to coach developers in a way that enables them to develop reliable code more consistently and faster. However, some organizations will use tools that leverage machine learning algorithms to identify developers who are not meeting expectations. That weeding out process is likely to begin much earlier in the application development life cycle as more advanced testing tools are embedded within CI/CD environments. Those tools won’t eliminate the need for developers and testers, but they do promise to increase dramatically the rate at which quality applications can be built and deployed at an industrial scale. Technical debt may never be completely eliminated, but at the very least the rate at which that technical debt is being accumulated should substantially decline.

It may be a while longer before machine learning algorithms and other forms of artificial intelligence (AI) are employed pervasively across DevOps processes. In most cases, those algorithms will help developers write better code faster. However, it’s also apparent there will be other algorithms at work that one way or another ensure developers will have fewer opportunities to make mistakes in the first place.

— Mike Vizard

August 13, 2019
A Culture-Driven Approach to DevOps Transformation
One of the most challenging aspects of a DevOps transformation isn’t automating and overhauling technology. The biggest challenge of DevOps is changing an organization’s culture and purpose. You can’t “buy a DevOps.” DevOps demands the involvement of people, process and tools working together.

Unfortunately, I’ve seen too many companies get carried away with the latest shiny object and neglect the people aspect. So, the end results they were expecting do not come to fruition. Research from Google Cloud and Harvard Business Review supports the importance of a people-first DevOps strategy. This research confirms DevOps transformation projects are worthless without addressing the people aspect.

Of course, such large-scale transitions are difficult. People have to put their reputations on the line to sell the transformation. Employees may become stressed or resist the cultural changes that come with a DevOps transformation. Therefore, communication throughout the entire transformation must be your primary goal. Communication includes measuring the effectiveness of the transformation vision and goals and sharing that information with your team. Keeping them informed ensures they understand the critical role they play in this vision, as well as the value of their work. These measurements need to also show how participation in change translates to value for the business.

Here are some best practices for prioritizing people and process when working through your DevOps transformation.

Communicate Every Step of the Way

It’s important to establish a level of empathy for your employees and understand exactly how changes will affect them. Employees’ professional identities develop over many years, and you can’t expect them to change overnight. Here are some questions your employees are wondering about:
- What happens to my job when we have to start adhering to this new process?
- Will I lose my job when all this automation is implemented?
- How am I going to learn the skills to be effective and contribute to this new way of working?
Expect their questions and listen for more areas of concern. Be proactive about sharing both the questions and the answers with everyone.

It’s critical that you keep an open channel of communication with your employees to help them through this change. Don’t view this as an add-on exercise–it should be the cornerstone. Focus on communication, and devote time to your staff, so they are completely integrated into the new DevOps process.

Your communication strategy needs to include all the teams involved with application delivery. Hold regular meetings across all departments, not only development and operations teams. Think about how the DevOps transformation impacts departments such as marketing, human resources and finance. What challenges have they run into? Have there been any negative impacts thus far? Listening and addressing each issue in real time will ensure the transformation is moving in the right direction.

Measure What Matters

When it comes to measuring your success, don’t worry about what other companies may be doing. The metrics that matter are the ones that support your ultimate business goal, which in this case is a better software delivery process.

Identifying metrics for your business demands you understand how your company’s process drives behavior. Ask questions such as: What corners were cut to get from development to production on time? Did meeting this deadline impact the timelines and performance of other teams and the quality of other applications?

Meaningful metrics allow you better insight into your processes in the real world. And meaningful metrics help determine whether your pipeline is moving in the right direction to deliver high-quality, high-value software.

Remember those regular meetings I mentioned earlier? These are also a great time to focus on metrics so employees understand how their work impacts the business. It’s also an opportunity to hear what’s happening on the ground in the delivery pipeline. This real-world information can determine progress, as well as test if the right metrics are being tracked.

Conclusion

A DevOps transformation requires changes to staffing, organizational structure, performance and culture. As a result, the success of your transformation involves moving the entire organization forward—building a strong culture ensures all people at all levels are invested in it. Measuring and communicating results must be the standard for every release you do.

DevOps can fundamentally change any organization for the good. By continually communicating a clear vision of the goals and expectations of your transformation, people will feel confident they are on a winning track.

— Tj Randall
August 9, 2019
Helping Developers Win in the Shift-Left Revolution

The shift-left revolution is upon us. Just because it’s a cliche, doesn’t mean it’s not true. As software development organizations continue to implement DevOps culture, processes, and tools, developers are adopting the practice of testing and ensuring the security of their applications as early as possible in the DevOps pipeline.

This is quite a change from the traditional waterfall method. There, developers dealt with the design and creation of a product or application and security professionals came in after they were finished, to review and test security, flagging any possible issues and sending them back to the software teams to figure it out.

This fundamental change in the way companies are addressing application security affects many of the moving parts in a software outfit. It requires a new set of processes, practices and tools all to be implemented, all while keeping up with today’s fast-paced release cycles.

To gain an understanding and insight on how developers are handling this hefty challenge, we polled more than 600 developers in software organizations and asked them about how security figures into their day-to-day tasks and processes, and the tools that help them to address their evolving roles.

Developers: Owning Their Shift Left

The first thing that we wanted to learn is whether developers are on board with the shift-left approach that most organizations have adopted for security testing. Our findings showed that, for the most part, developers are taking ownership of the day-to-day operational responsibility for AppSec in their organizations, playing a more significant role on this front to secure their products.

When asked who owns the day-to-day operational responsibility for AppSec in their organizations, 23% answered that developers own those responsibilities, 21% said DevOps, 28% said software development team leaders owned it and only 29% said security teams in their organizations are the owners.

The fact that a whopping 71% of developers put the ownership of AppSec squarely on the shoulders of software development and DevOps folks means that developers are very much on board with the shift-left movement and have taken on the new security tasks that come along with that.

Breaking it down, we also found that in smaller organizations, more developers and DevOps professionals feel that they own their AppSec responsibilities, while those percentages go down with larger organizations. This can be explained by the fact that often smaller companies have less specialization, requiring developers to branch out of their professional comfort zone. Smaller organizations also tend to allow developers more freedom and flexibility to define their own processes.

Do these responses mean that in addition to their focus on innovation, functionality and quality, developers have also added security into their considerations when they are in the process of creating and building projects?

The answer would appear to be yes, according to 58% of developers in our survey, with an additional 39% saying that security figures into their consideration when issues arise (14%) or that they validate security before deployment (25%). Only 3% of developers said that security is none of their concern since it slows them down.

Are you taking security into consideration when developing software?

While their responses show that there is still a ways to go before security is completely baked into development processes, it’s clear that most developers are already in the right direction, making security a priority within their tight schedules.

The AppSec Process: Who’s On First?

How does making security a top priority or at least a consideration figure into the different phases in the DevOps pipeline? Practically, where is it being applied? We asked developers at which phase in the software development life cycle (SDLC) they started testing their AppSec.

Their answers showed once again that developers are taking on security where it traditionally was not a part of their workflow. In fact, many replied that they are integrating security testing tools as early as the pre-build stage, with 36% of the respondents saying that they are testing in their IDE and repositories.

Survey results also showed that along with the DevOps processes, they are also adopting tools that help them to shift security further left. 68% of developers report using at least one AppSec technology such as SAST, DAST, SCA, IAST or RASP. All of these automated solutions help security teams and developers detect potential security issues in their products, providing software teams with visibility and control over their AppSec.

A Question of Remediation

Until now, survey results show that developers have taken their place on the front lines of AppSec and the shift-left revolution, arming themselves with an impressive collection of automated detection tools. However, these solutions are creating a new set of issues that should worry stakeholders.

It appears that the much-needed security testing tools are threatening to bury development teams under a mountain of alerts, which they are now required to research and remediate while keeping up with their deadlines. It’s impossible for developers to keep up with all of the security alerts in their inbox, especially considering that many AppSec tools were developed for security teams and focused on widespread coverage (detecting all potential issues), rather than accuracy and prioritization.

This poses quite a challenge for developers, who say that they are spending a substantial chunk of their very valuable time dealing with remediation-related tasks. A full 42% of the respondents reported that they spend between two and 12 hours each month on these tasks, while another 33% said that they spend 12 to 36 monthly hours on them.

In light of these time-heavy statistics, it is clear that developers need new technologies and practices that will allow them to prioritize security without slowing down the development life cycle and costing them so many valuable work hours.

Helping Developers Win the Race to Remediation

The survey results showed that developers today are required to take the lead when it comes to application security, but need more backup to do so. Detection tools can take developers part of the way, but to empower them through to remediation, organizations must provide them with developer-focused solutions that can help them to close the loop from detection to remediation.

Once developers are alerted to a newly detected security vulnerability in their project, they need to validate it, assess its impact, research remediation options and perform the remediation path chosen. Currently, these are all time-consuming manual processes that require a level of skill and proficiency.

With developers poised to face security head-on, organizations expecting them to fully address AppSec need to provide them with the tools that will easily integrate into their native environments and help them take vulnerability management one step further, enabling them to prioritize security alerts so that they can get to the most burning issues first and even automate their remediation process.

— Ayala Goldstein

August 7, 2019
Mendix Injects More AI to Accelerate Low-Code Development

The rate at which low-code applications are built and deployed will accelerate as developers begin to rely more on artificial intelligence (AI) to write code. The summer 2019 release of the Mendix low-code platform includes a revamped instance of Mendix Assist, which employs machine learning algorithms to make coding recommendations. Those algorithms have been trained using data drawn from 5 million application models employed across 15 industries over the last 10 years, and Mendix claims this version of Mendix Assist improves the accuracy rate of the recommendations being made to 95%.

Sheryl Koenigsberg, director of product and solutions marketing for Mendix, said Mendix Assist will enable new developers to write better code faster, while experienced developers will be able to employ Mendix Assist to address routine issues that often get overlooked faster. Mendix Assist not only advises developers on what to do next but also generates recommended actions in previous logical steps based on whatever new code is introduced in the application.

To make these capabilities more accessible, the summer release of Mendix adds Mendix Studio and Studio Pro, a set of integrated development environments designed to be accessible to both citizen and professional developers, to the low-code platform.

In addition, Mendix is adding support for native mobile application development by adding support for React, a set of JavaScript libraries for building user interfaces for mobile applications, and including a native JavaScript editor. Those capabilities eliminate the need to rely on emulation software when building mobile computing applications, said Koenigsberg. Because the Mendix IDEs integrate low-code abstraction across iOS, Android, Java and Objective-C programming models, it also becomes easier for mobile developers to build reusable components. Mendix has also included more than 50 pre-built connectors to mobile device capabilities, such as camera, geolocation, biometric authentication and Bluetooth enablement, along with support for conversational chatbots and voice interfaces such as Alexa and Siri.

Longer-term, Koenigsberg observed that it’s conceivable the AI capabilities being included in application development tools eventually will share insights with AI models being incorporated into continuous integration/continuous deployment (CI/CD) platforms. Proposed changes to an application could, for example, might be assessed from a performance perspective before any lines of code are written.

In the meantime, the rate at which low-code applications will be moving through CI/CD platforms is about to increase substantially as developers augment their own skills by relying more on recommendations surfaced by AI engines. The quality of those applications should also improve as AI engines check, for example, to make sure all the appropriate compliance and cybersecurity controls are in place.

It’s not likely AI engines will replace the need for developers anytime soon. However, it is apparent all the little things that routinely conspire to slow application development and delivery processes increasingly will be automated. That should make it easier for a larger number of organizations to embrace best DevOps processes. After all, the primary issue with DevOps adoption these days is not necessarily appreciating the value of the concept, but rather managing pipelines that still tend to get clogged every time an application fails to pass a gate because a developer forgot to do one thing or another.

— Mike Vizard

July 26, 2019
Stackery Smooths AWS Serverless Integration for DevOps

Stackery today announced a plug-in capability that will allow developers to build and debug code destined to run on the Lambda serverless computing service provided by Amazon Web Services (AWS) from within an integrated development environment (IDE) running on a local machine.

Company CTO Chase Douglas said the latest Stackery tool can be dropped into any IDE, either via a Stackery VS Code Serverless Tools Plug-In that automates installation or a manual installation process, regardless of the programming language being employed. The goal is to make it easier for DevOps teams to construct workflows that include AWS serverless computing frameworks, which now are expanding rapidly, he said. In total, the Stackery tools can invoke any one of 86 AWS CloudFormation-compatible resources.

Stackery provides a set of visual tools that make it easier to write functions for the AWS Lambda service without having to know how to create YAML files to manipulate infrastructure as code. This latest offering extends that capability to local environments, which will allow DevOps teams to work offline on their laptops and make changes without having to make every change on the AWS cloud over an internet connection. This capability does not require customers to set up a Stackery account to use it.

Right now, Stackery is squarely focused on providing those tools for AWS environments, but Thomas said eventually those tools will be extended to other serverless computing environments.

The goal is to provide DevOps teams with tools that make all serverless computing frameworks more accessible to both developers and IT operations teams, Douglas said.

Serverless computing frameworks are gaining in popularity because they make it easier for developers to invoke additional IT infrastructure resources to kick off, for example, an analytics module whenever a certain event occurs within their application. That capability reduces the amount of code developers need to include in their core applications. Serverless computing frameworks are usually employed to run stateless processes for a very short amount of time, while containers and virtual machines continue to be relied on for running longer running applications. But for DevOps, that creates another layer of abstraction to include within the context of a larger continuous integration/continuous deployment workflow.

Most organizations are already struggling with mastering the workflows they employ to manage the building and deployment of applications using containers and virtual machines, so any new abstraction layer of compute resources need to incorporate within the workflows easily if the providers of that service hope to achieve mainstream adoption among DevOps practitioners. Long-term, of course, the expectation is all these processes will be completely automated, which means developers only will have to ever worry about writing business logic.

In the meantime, it’s likely to be a while before DevOps shops are invoking multiple serverless computing frameworks running on different clouds, much less automating them on end to end. That day, however, may not be as far off as people today might assume.

— Mike Vizard

July 25, 2019
Consider the Role of Programmers as Storytellers
Every time I speak with the programmers of our team in casual conversation, I ask what they’re working on. Every time, I get the same kind of answer, “I’m building a dashboard,” or “I’m optimizing a database,” or “I’m testing the user interaction.”

In other words, I get the same answer as the proverbial masons, “I’m laying bricks,” or “I’m building a wall.” But not, “I’m building a cathedral.”

At an abstract level, programmers understand the value of the big picture. But at a practical level, they focus on the immediate next steps. Since time is always crunched, programmers skip absorbing the big picture.

“This is a mistake,” I told them. “Your work improves if you know why you’re doing what you’re doing.”

“How?” the curious ones asked. That’s when I told them the story of Andre.

Andre told me he was creating a dashboard. I decided to ask him the five whys.
1. “Why are you building this dashboard?” I asked. “Because my team leader told me to,” said Andre.
2. “Why does he need it?” I then asked. “Because the client Rudolph told him to build it,” he answered.
3. “Why does the client need it?” I continued to ask. “Because his boss told him … I guess?” he replied.
4. “Why does his boss need it?” I asked him. “I don’t know,” he said.
I knew I couldn’t get further. So, I asked to see the dashboard. It showed 14 metrics and their performance across time. I had no idea what I was supposed to infer from the numbers.

I spoke to Rudolph, the client, and asked why he needed the dashboard. His answer was similar, “Because Victor, my boss, wants to know how our operations are doing.”

“So, do you need all 14 numbers? As a table?” I asked him. “Yes,” he said. “I need to know how each number is performing.”

I tried a different tack. “Suppose you’re on an elevator with Victor, and he says, ‘Hi Rudolph, how’s it going?’ How will you answer? Are you going to recite all 14 numbers to him?”

Rudolph thought for a while and said, “No. I’ll probably just tell him about what’s improved and what’s worsened. Then I’ll tell him what I’m going to focus on improving. That’s all that matters to him.”

That left Andre and me wiser. Our aim was not to show 14 metrics. It was to help Rudolph and Victor figure out what’s improved and worsened.

This helped Andre change three decisions.

Change the Development Priority

Not all metrics were equally important. Some were consistently stable. Some fluctuated a lot. He wrote the queries for the fluctuating metrics first. So, when the deadline hit and he wasn’t fully ready, he still had the most important metrics in place.

Change the Design

He added simple traffic-light colors to the metrics that grew the most and fell the most. It made it much easier for Rudolph to figure out what’s improved and what’s worsened. Rudolph never commented on it. But we knew without it, his response would have been, “There’s something wrong with this, but I don’t know what.”

Change What to Optimize

The queries run slowly. Rather than optimize all queries, Andre reordered the queries to render the fluctuating metrics first and optimized those. Those results appeared first, markedly improving how fast the dashboard appeared to load.

Conclusion

There’s a reason modern agile processes refer to user stories to capture requirements. But we lose the spirit of the story when we write, “As a user, I want to see the performance of 14 metrics.”

The next time you write a requirement, don’t hesitate to write the full user story for the programmers. “When my boss is in the elevator and asks for a quick summary, I want to tell him what’s improved and what’s worsened, in less than 10 seconds.”

Stories are memorable. They are easier to understand and communicate. They help explain why we’re doing what we’re doing. They also help prioritize development, improve the design and optimize better.

Always ask for requirements as stories. Always narrate requirements as stories.

— S. Anand
July 24, 2019
3 Reasons Why Ephemeral Access is Best for DevOps

Recently, we worked with a customer, MOST Digital, whose developers were struggling with a common workflow challenge we hear from many companies.

The company is in the software robotics automation space—it essentially makes little robots that automate all sorts of business processes for a company, such as HR report filing or routine emails. MOST Digital developers need access to customer environments to fetch data, often jumping in and out of on-premises and cloud platforms to do so.

The problem was developers had to use client-specific jump hosts and VPNs to transition between IT resources. The process was slow, complicated and difficult to manage, which made life more difficult for MOST Digital’s team. Projects were delayed as they had to wait to receive help from each client’s IT organization.

“This wasn’t what MOST Digital wanted for their team,” said Sami Säisä, director and head of strategic development at MOST Digital. “We want to provide them the best environments and best tools that there are available.”

It’s a common refrain we hear from many customers, and it makes sense. The easiest way to frustrate a developer is to throw obstacles into their workflow. Unfortunately, most common secure access solutions create obstacles, and it’s not just jump hosts or VPNs. Even privileged access management (PAM) solutions, which are supposed to simplify and centralize IT credential management, are traditionally too bulky, complicated or non-intuitive for modern workflows. That encourages developers to bypass PAM altogether, which creates a major security risk.

So, what’s the best way to overcome the complexity brought on by credential management? Well, why not just get rid of permanent credentials?

Ephemeral certificates are a modern form of secure access that are temporary, time-based and automatically expire. Here’s why they’re a better solution for companies that want to keep modern developers happy.

Ephemeral Certificates Offer ‘Just in Time’ Access

Developers are building and coding in a world that emphasizes speed, agility and elasticity. They’re taking advantage of state-of-the-art tools meant to make it faster and easier to do work. They’re taking advantage of modern, hybrid IT environments that combine multiple cloud infrastructures in an attempt to find the most effective mix of resources for development and deployment.

The last thing they want are processes that slow down workflow. Unfortunately, secure access today often means doing just that: slowing down and stopping to manually input credentials across environments. Developers might also share credentials among each other to try and speed up work, but that creates yet another security risk.

Traditional PAM solutions don’t make the process any easier. Those tools create a central vault to manage an organization’s secure credentials. Privileged tech users, such as developers, have to use them to access and authenticate their credentials. PAM grants access per user and per host, so a new, permanent credential needs to be created every time a new developer, contractor or contributor needs access to a new IT resource.

However, most PAM tools were not built with the workflow of the modern developer in mind, so they slow things down while also encouraging loopholes and workarounds that compromise organizational security.

Ephemeral certificates overcome all of this by eliminating manual credential inputs. Gartner refers to these as just-in-time access, because access credentials are created on-demand automatically and require no installation, configuration or updating. In other words, they free developers to focus exclusively on the work they do best.

Ephemeral Certificates Eliminate Bad Habits

Rather than deal with all of the typical secure access challenges, some developers will often bypass PAM solutions altogether, instead choosing to spin up their own SSH keys to access the IT resources they need. Those keys exist outside of the PAM solution—they are untracked and unmanaged.

Not only is it a policy violation to have developers find workarounds for IT-approved security practices (not to mention a huge waste of the investment in a PAM solution), but it also creates a security risk.

The best way to encourage policy adherence is to make your policy easy to follow. Developers won’t bypass your security solution if it’s easy to use, and ephemeral certificates are inherently simple.

There Are No Credentials to Misplace–Or Have Stolen

If every developer is creating their own SSH keys to access IT assets and no one’s keeping track of them all, what happens if one is lost or when that developer leaves the company? Suddenly, there are keys laying around that could be scooped up and used as an all-access pass to systems in your environment.

How do you monitor and audit this type of shadow IT access? How do you trace non-policy compliant access from development to production? How do you prevent developer access to sensitive data?

Ephemeral certificates are inherently more secure because they are temporary, only existing for the period during which access is required, and automatically expire as soon as you are done using them.

As a result, there are no credentials to lose, misplace or steal, leaving fewer old credentials lying around for someone to take advantage of down the road. On top of that, ephemeral certificates don’t leave user-specific access credentials stored on target servers, so if someone does get access to your target server, they won’t be able to find any credentials that could be used to hop to other systems.

Ephemeral Access Is a Step Closer to DevSecOps

From security to IT management, there are lots of reasons why ephemeral certificates are a better solution for businesses. But the single most impactful use case is making your team’s life easier.

Want to frustrate a developer? Throw some obstacles into their workflow. But if you want to keep your developers busy on value-driving activities, get rid of outdated and unmanageable workflows. They’ll thank you for it later.

— Markku Rossi

July 23, 2019