Tag: development

  • Solving the DevOps Accountability Problem

    DevOps accountability is the idea that both the development and operations teams have equal responsibility for success. But putting this approach into practice has been a thorn in the side of DevOps teams for the past decade, largely due to outdated organizational structures that place responsibilities on a single employee or team.

    These outmoded structures restrict the lean flow of operations needed for DevOps and contribute to costly downtime when issues arise. But redistributing functions across the organization can help solve this problem. 

    For cross-functional teams that rely on organization-wide collaboration, redefining the org chart can clarify ambiguities about accountability and help organizations overcome internal obstacles.

    Legacy Organizational Structures

    Many organizations have not instituted an organizational structure that reflects a shared accountability model. This is partially due to leadership’s assumption that large teams work faster and more dynamically. In reality, after a team exceeds nine individuals, the rate of return diminishes and people are more likely to assume someone else on the team will take responsibility for a task. As a result, accountability falls through the cracks.

    Additionally, there is frequently an imbalance in assignments and responsibilities between junior and senior employees. When senior employees take on the majority of important or interesting tasks, junior employees can feel overlooked and less responsible for their team’s success. This is both an individual and a company-wide issue; younger workers tend to bring fresh perspectives and insights—they can also adapt more quickly to unprecedented changes and issues.

    Picture a team consisting of a line manager and team members, with a structure that places all major responsibilities on the manager. If the manager happens to be out of the office when an issue arises, the team would have to wait for their boss’s return to resume operations.

    But the consequences of single-point accountability go far beyond lost time and downtime costs. When employees feel like they don’t have a significant stake in a project, they feel less aligned with the organization’s overall purpose and are less likely to be engaged.

    DevOps is most effective when teams are built around a common goal rather than around the performance of individuals. If an employee can’t see the impact their work is having on the overall organization or project, it can create blind spots and disconnect between the business and its people. Shifting business frameworks is no easy feat, but with the right strategy, it can improve how tasks and responsibilities are allocated in your organization.

    Three Ways to Switch up Your Org Chart for Greater Accountability

    The days of allowing responsibilities to fall on a single employee are over. But to successfully embrace a shared accountability approach, you need to reimagine your entire organizational chart. Beyond de-prioritizing seniority and minimizing team sizes, consider these three initiatives to help settle DevOps accountability issues:

    1. Blueprint your organizational structure around products. Organize your work structure around products—not projects. Traditional project management models rely on passing responsibilities between specialized teams, which can slow down innovation and degrade the quality of work. With an organizational structure built around products, you can build a cross-functional team with all necessary skills for each system. For example, if you have a team that’s accountable for the payroll system, all necessary expertise you need to keep that system running smoothly is based on a single contact point.
    1. Redistribute talent. The product-oriented approach requires changing up talent distribution across teams. Let’s say you have a 24-person team for a single SaaS product and seven of those team members have similar skill sets and backgrounds. In this instance, you could move several of those workers to a different team where their skills are in demand.
    1. Establish hybrid workplace environment norms. Face-to-face communication has always been a critical part of successful teams. But in light of the COVID-19 pandemic, workplace norms are evolving and organizations need to adapt to new ways of working. Many teams are no longer able to participate in informal knowledge sharing and other typical in-office interactions, so it’s critical to identify new norms for your team. Initiate conversations about applying DevOps concepts in a hybrid world, along with creating rules of engagement and accountability that are realistic for remote work.

    The Great Redistribution

    As technology advances, so should your organizational structure. To optimize efficiencies and ensure products reach the market on time, consider rethinking your org chart. In practice, this will enable you to more seamlessly adopt a culture that celebrates shared responsibility and employees who feel they have a stake in your product’s future.

  • Languages and DevOps: Network

    Languages and DevOps: Network

    It is fun to discuss the changes in network operations over the last couple decades. We’ve come full circle, and, honestly, ended up in a better place. Network specialists were super command-line wizards who kept us going, with few GUIs in sight. Everyone thought the next iteration would be GUIs, so network operations could be accessible to more than a few command-line specialists. “Everyone” was mostly right; we did head in that direction. It was optional, and many network operations friends pointed out that you could still do more, faster with the command line. Before GUIs had the opportunity to catch up with command lines, though, automation came along. And then DevOps. And finally,* configuration-as-code. Pretty quickly, the ability to do everything through an individual product’s GUI was determined to be a weakness. Network operations personnel were dealing with more vendors to handle the networkification (it is too a word! I just made it up) of common development activities, like some aspects of security. And now, APIs and command lines rule the juncture of DevOps and networking.

    *Finally – so far, at least

    And that shows in languages. Shell scripting and Python run this show, with little competition from any other language. We could get into a massive discussion about whether shell scripting is programming, but we won’t, because at least in networking, it most definitely is considered to be programming.

    One time, when we were tracking down a problem that involved all of IT, I was sitting with the serious network geeks and marveling at their ability to make everything they wanted happen from the command line in an instant, and their ability to parse command output. I’m no slouch when it comes to networking, but they easily put me to shame. I got to chatting with a few of them, and the consensus was that they loved computing but hated programming. Networking made sense to them. This explains why networking DevOps people are continuing to use Shell scripting and adopting Python at the same time.

    Python and Shell

    Shell is a given in networking. There are a lot of extant Shell scripts for doing all sorts of things, and the need to automate to keep up with Agile makes shell scripting a logical choice.

    Python enters the picture because it is “common ground.” It is intuitive enough for most networking people to do what they need to get done, and known or knowable to most developers. When it comes to usage, Python has overtaken Shell; (don’t take my word for it, check out the excellent work of the NetDevOps survey on GitHub, or just glance at the graphic below, created by them) in fact, Shell and Python command so much of the network development space that you are probably better off just making sure you’ve got those down, and focusing your free time on other issues like completely different networking commands, or even skills for data center versus cloud. The ROI would be better.

    But Wait, There’s More

    The key operational changes recently have been around GitOps and reporting back into the DevOps toolchain. People no longer want your appliance or application to have a pretty GUI, they want it to report in to the tools that provide automation and a larger-picture GUI. Many vendors are there already, but many are not yet. That creates a need for tools – products, open source projects, or internally developed – to do that integration while waiting for the vendors to catch up. These, again, are well-served by Python, though other languages that can handle APIs are viable, too.

    We’re headed for a world where systems detect anomalies and react to rectify them, but we’re not there yet – not on a strategic scale, at least. And we probably won’t be for some time, as automating massive network changes is a scary proposition and will take time to use these systems for detection, monitoring what they could have done, before organizations are willing to let them “just do it.”

    Carry On

    Meanwhile, NetDevOps is getting folded into DevOps proper, and in many organizations, using infrastructure-as-code or GitOps, is being deployed and managed like any other part of the life cycle. So we are moving along. For my network peeps, your job will continue to change, but it certainly won’t go away. You’re essential to smooth-running systems, and while the network may become even more virtual, it will still be networking. And under that virtual network will be … a physical network. So keep kicking it, and carving a path from users to apps, while protecting those apps and ensuring they have adequate resources. Oh, and if I spin up another instance at midnight, you’ll hop on and make sure it’s got traffic directed to it, right? RIGHT?!

  • Low-Code To Become Commonplace in 2021

    Low-Code To Become Commonplace in 2021

    A new study finds 85% of engineer leads predict low-code and no-code will soon become common

    New findings from an Internal-endorsed study suggest 2020’s software development challenges will undoubtedly carry into 2021. Many businesses are making immediate transitions to a digital-only economy, forcing a ton of new app development requirements. Yet, hiring top engineering talent is especially difficult, amid a developer drought and pandemic uncertainties.

    One in three organizations has implemented a hiring freeze. Respondents also cited rising development challenges and insecure internal software, putting a strain on normal operations. To help address these challenges going forward, a whopping 85.1% believe implementing low-code and no-code will become more and more omnipresent within their company.

    Below, we dive into the report’s major findings, which surveyed 500 IT and engineering workers at medium-to-large enterprises. Using this data, we’ll forecast hurdles software development teams may face in 2021, and gauge if low-code tooling adoption is the ultimate panacea or no more than a Band-Aid for a much larger ongoing problem.

    Development Challenges Will Increase

    In the thick of the pandemic, software is often the only touchpoint many traditional companies have with a user. Naturally, the number of digital experiences required to meet this new reality is skyrocketing. Experts and data show this trend has no signs of stopping.

    In fact, 60.1% of surveyed saw app development increasing due to work-from-home policies. Only 9.7% reported a decrease in app development. One could easily attribute rising app development with growing software requirements brought on by the current digital-first climate.

    In this new economy, finding bold ways to increase productivity is critical. Improving the efficiency of engineering teams was a priority for most respondents and a high priority for 40% of respondents. For small groups with lean margins, improving automation for software delivery could help compete with larger players.

    Talent Will Become More Competitive

    The biggest challenge employers face is finding talent—30.6% of respondents cited increased competition for talent as a top challenge in 2020 and 22.2% also recognized developer drought as a significant obstacle. If you had trouble finding skilled software engineers in 2020, good luck next year …

    Looking to 2021, 45% see competition for talent remains a top challenge. Trailing problems include developer drought, immigration issues and a poor reaction to new work-from-home policies.

    Hiring Practices Will Continue to Shift

    With COVID–19 in full force and a developer scarcity, you’d think hiring would come to a freeze. Yet, the results of this study were mixed—hiring practices are pretty varied across teams.

    According to the report, 34.5% of organizations surveyed had paused hiring new engineers. Conversely, 37.3% have hired more engineers, and 18.5% of organizations reported no change to hiring practices at all. About 10% had layoffs.

    Whereas some tech companies are thriving in the new normal, others may pause hiring due to uncertainness around COVID-19. These companies could be turning to low-code technologies as a replacement. “If you pause hiring, you still need to build, and low-code is a great option for that,” said Arisa Amano, CEO of Internal.

    Low-Code Will Become Commonplace

    To address the above issues, companies are turning to low-code solutions. These platforms help relieve the development burden for internal business tools and open up citizen developer use. And, it’s more than a fad—the report was able to squarely demonstrate an uptick in low-code use.

    Most companies (75.2%) have already implemented a combination of low-code and traditional engineering methods. It appears that low-code is complementing existing software engineering practices at a number of institutions.

    In addition, 28.8% of respondents predict low-code and no-code will become a high priority in the coming months, and for 21.6%, it will become an essential focus. Impressively, 85.1% of developers foresee low-code and no-code as becoming more commonly implemented within their company.

    Low-Code Will Open Doors for Non-Tech

    The citizen developer concept has been gathering marketing steam, but it might not be just hype. Now, data suggests low-code tools are actually opening doors for such non-developers. Seventy percent of companies said non-developers in their company already build tools for internal business use, and nearly 80% predict to see more of this trend in 2021.

    It should be noted that low-code and no-code do not seek to replace all engineering talent; instead, to free them up to engage in more complex tasks. “With low-code, you free up your engineers to work on harder problems, instead of having them work on basic things,” said Arisa Amano, CEO of Internal. She believes this could translate into more innovation companywide.

    Surprisingly, bringing non-traditional engineers into the development fold is not being met with ambivalence—69.2% of respondents foresee that citizen developers positively affect engineering teams, with the rest primarily exhibiting a neutral reaction.

    Improved Access Control Will Boost Internal Security

    The costs of internal security threats are high. Breaches could decrease customer trust, harm brand reputation and lead to escalating legal fees. With cyberattacks a prevalent concern, cybersecurity must come back in style.

    Not only are threats external, but internal too—46.8% of respondents were extremely concerned about employees having access to customer data. The cause for concern is duly noted, as the majority, 58.1%, have experienced internal data security breaches in the past.

    The reasons for internal breaches vary across the board. Respondents attributed the top cause simply to a rise in the number of employees and contractors with access to sensitive information—a surge in employees means a greater chance of human error or leaked credentials. It also means an increase in the number of devices with access to sensitive data—this is particularly tricky, as CISOs face a dilemma on how to govern privileged access for housebound laptops and mobile devices.

    Respondents also noted the increasing complexity of technology and the overabundance of new cloud applications. It’s hard to expect DevOps to secure modern infrastructure when they’re still trying to figure out how it works! As a knowledge gap could quickly introduce vulnerabilities, 62.7% of respondents are actively investing in increased employee security training.

    Other security problems, such as a lack of granular access control or lack of logging and audit trails, seem like they could be mitigated with the right configurations and DevSecOps approach. In fact, 55.4% of respondents are in the process of baking in fine-grained access controls. “Having that at the forefront of internal tools is key,” said Bob Remeika, co-founder, Internal.

    Shifting security left could correct an age-old trend of adding security after the fact, which only prolongs the problem. On the whole, companies require a combination of better access enforcement, multi-factor auth and increased monitoring to mitigate mounting threats.

    Low-Code Becomes Mainstream in 2021

    Software development teams face many challenges in the coming year. Demands for new software will increase and processes to increase efficiency will fall under the microscope. Rising engineer competitiveness and developer drought will also continue to shift hiring practices.

    Companies that weren’t 100% digital will be forced to embrace the new norm and develop internal software and automation. Yet, building internal tools isn’t straightforward and will be especially difficult for companies less technical than their software-as-a-service counterparts. All this, paired with ongoing security threats, means internal app development in 2021 has its challenges.

    Although conditions look dicey, the underlying issues are not unusual, Remeika said. They have just been amplified. “There’s always been a developer drought, companies have always been trying to find ways to do more with less, and competition for talent is never getting less fierce,” he said.

    Though we’ve seen a spike since COVID-19, the desire to offload work has been everpresent. Remeika believes sophisticated low-code platforms will empower technical non-engineers and assist with things people typically tend to disregard when building internal applications, such as security, deployment, testing and review capabilities.

    Nevertheless, development team output appears to be resilient throughout work-from-home policies. And as I recently covered, a low-code movement could also enable a democratization effect, helping SMEs who can’t afford the top talent to still compete at the same table as large tech companies. We expect low-code and no-code adoption to spill well into 2021, seemingly, as a panacea to these mounting concerns.

  • New AWS Services Optimize App Development Process

    New AWS Services Optimize App Development Process

    Amazon Web Services (AWS) is always busy introducing new services, enhancing existing ones and, quite often, driving trends. However, the cloud services provider has upped its game even more in recent months.

    In the first half of 2020, AWS announced an astonishing number of developments that enable technology interoperability, simplifying legacy feature removal, creating greater flexibility and time-savings for developers and putting new capabilities at users’ fingertips.

    AWS and ARM Power

    You are going to be hearing a lot about ARM processor architecture and not just because the chipmaker is being acquired by Nvidia, the leading maker of GPUs.

    Developed in the 1980s, ARM processors are finally hitting their stride as companies are embracing ARM-based chips. ARM-based processors combine high-performance RISC designs, lower manufacturing costs and reduced power consumption, making them ideal for portable devices such as smartphones, tablets and even laptops. More and more companies are designing processors that implement ARM architecture, including Apple, AppliedMicro, Broadcom, Qualcomm and Samsung Electronics. This year, Apple brought ARM chips into the desktop world with tailored extensions such as a built-in security enclave, a motion co-processor and a neural engine.

    AWS is among those embracing ARM architecture, which has led to introducing an array of robust services that will benefit developers and end users alike. Case in point: This summer, AWS announced the general availability of its sixth generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, including general-purpose (M6g), compute-optimized (C6g) and memory-optimized (R6g) instances. Powered by AWS-designed, ARM-based Graviton2 processors, they deliver up to 40% better price/performance over comparable current-generation x86-based instances.

    They also offer 50% more NVMe SSD storage GB/vCPU over comparable x86-based instances. The local SSD storage works well for apps that require high-speed, low latency storage, as well as for temporary storage of data such as batch and log processing, and high-speed caches and scratch files.

    They’re ideal for workloads ranging from application servers, microservices and high-performance computing to CPU-based machine learning inference, electronic design automation and gaming. Numerous organizations have already successfully adopted ARM-powered instances and are realizing price/performance benefits.

    The AWS Graviton-based instances are supported by a broad ecosystem of operating systems and services from independent software vendors (ISVs) as well as AWS. They can be purchased as on-demand, reserved, or spot instances; covered by savings plans or as dedicated hosts/instances, and support up to 19 Gbps Elastic Block Store (EBS) bandwidth.

    The AWS Graviton2 processor itself, released in late 2019, deserves recognition, too. Compared to first-generation ARM-powered Graviton processors, they provide twice as fast floating-point performance per core for scientific and high-performance computing workloads. They also offer optimized instructions for faster machine learning inference, always-on fully encrypted DDR4 memory and 50% faster per core encryption performance to further enhance security.

    A number of AWS services, such as Amazon Elastic Load Balancing, Amazon ElastiCache and Amazon Elastic Map Reduce, have realized superior price/performance in testing and will be moving into production on Graviton2-based instances.

    Better, Easier Artifact Management

    AWS isn’t the only organization opting for ARM. As many others prepare to make a move, AWS is doing its part to facilitate the transition. That includes deploying services that streamline various aspects of the app development process, in keeping with the efficiencies and increased performance offered by ARM-based chips.

    One that we’re most excited about is AWS CodeArtifact. This fully managed software artifact repository service eliminates the need for setting up, operating and scaling the infrastructure required for artifact management. It works with commonly used package managers and tools such as Maven and Gradle (Java), npm/yarn (JavaScript) and pip/twine (Python), so it can easily be integrated into existing development workflows.

    AWS CodeArtifact can be used for creating centralized repositories for sharing software packages approved for use across development teams. Its integration with AWS Identity and Access Management (IAM) enables access control. Its support for AWS CloudTrail provides visibility into which packages are in use and where they can easily be updated or removed.

    AWS Making Containerization Easier

    Using containers to modernize existing apps make them portable, increases development agility and reduces operational costs. The problem is that the process requires numerous manual tasks that are time-consuming and error-prone, and slow down modernization efforts.

    That’s why we think another recently deployed AWS service will have a positive impact on the app development process. AWS App2Container is a command-line tool that helps containerize existing apps running on-premises, in Amazon EC2 or in other clouds with no code changes required.

    App2Container discovers apps running on a server, identifies their dependencies and generates relevant artifacts for seamless deployment to Amazon ECS and Amazon EKS. It also provides integration with AWS CodeBuild and AWS CodeDeploy for a repeatable way to build and deploy containerized applications.

    AWS App2Container generates artifacts such as Dockerfiles, container images in Amazon Elastic Container Registry (ECR), ECS Task definitions, Kubernetes deployment YAML, templates to set up a build/release pipeline in AWS CodePipeline and more.

    It can also be used to containerize ASP.NET (.NET 3.5+) web apps running in IIS 7.5+ on Windows and Java apps running on Linux.

    Code Review and Optimization

    Another handy tool that debuted this summer is Amazon CodeGuru. Powered by machine learning, this set of tools automatically reviews code for bugs and suggests potential optimizations. It includes two components:

    • Amazon CodeGuru Profiler—Helps developers find an app’s most expensive lines of code and then recommends how to improve the code to save money.
    • Amazon CodeGuru Reviewer—Helps improve code quality by using machine learning to identify critical issues and hard-to-find bugs during development.

    Do-It-Yourself Development

    One more recently released AWS service we want to mention is Amazon Honeycode. This one has the potential to be a big time-saver for customers. The fully managed, low-code/no-code development tool makes it easy to build powerful mobile and web apps quickly with no programming required.

    Customers can use a simple visual app builder to create highly interactive web and mobile apps, backed by an AWS-built database to perform tasks such as tracking data over time and notifying users of changes. They can get started creating apps in minutes and build applications for up to 20 users for free. After that, they pay per user and for the consumed storage capacity.

    What’s Next With AWS Is What’s Now

    AWS is continually developing and deploying services that make app development easier and more cost-efficient. You can put these new services to work to innovate more, get to market quicker, generate significant cost savings and much more.

  • Engaging Developers in a Post-COVID-19 World

    Engaging Developers in a Post-COVID-19 World

    The time for platforms to rethink how they engage developers is now

    How we communicate, socialize, look up information, work, shop and travel have all been transformed by platform companies. COVID-19 has only increased our reliance on these platforms, as people spend more time on the internet and businesses migrate from offline to online offerings.

    These shifts present challenges to the platforms themselves. With people increasingly using low-latency applications such as teleconferencing and video streaming, there’s much more demand for data to be delivered without noticeable delays. As more and more varied businesses migrate their services online, it creates additional burdens on platform infrastructure and stretches the limits of their functionality.

    It’s a challenging environment for platform companies. But disruption also presents opportunities. The question becomes, “What do platform companies need to do to remain relevant and to improve their products and services?“

    The Importance of Developers

    There are some obvious starting points. Platform companies will need to rapidly adapt their offerings according to their evolving user base. They’ll also need to plan for commercial sustainability and make sure that they balance short-term expenditure with longer-term profitability.

    But they will not be able to do these things alone. With almost 24 million developers in the world today, external developers are central to any platform’s effort to adapt their products and expand commercial sustainability. As the technology industry continues to be subject to disruption, the developer ecosystem is ideally placed to drive expansion at a sustainable scale, enable product differentiation, reduce time-to-market and ensure relevance through product-driven growth.

    Those platforms that can successfully engage developers will stand out from the crowd and win the increasingly competitive fight for developer loyalty. Similarly, as developer ecosystems increasingly become a key differentiator, the platforms that fail to engage developers may also fail to keep up with the rapidly changing technology landscape.

    Developing Developer Partnerships

    It’s clear that platforms will need to make engaging developers a priority moving forward. The question is, how?

    For a start, organizations need to have a clear sense of which parts of their ecosystem can be opened up quickly and which integrations need to be built into the platform. With these established, the next step is to engage the developers that are best placed to help.

    At the core of engaging developers successfully is the recognition that different developers will have different priorities, needs and core skillsets. All developers need to secure ROI by engaging with the platform and its ecosystem. But their perception of value will differ. Enterprise developers, for example, rate ease of use, peer perception, strong developer tools, accurate content and enterprise-level support. Independent software vendors (ISVs), however, care most about revenue, lead generation and being pulled into deals.

    Segmentation, Segmentation, Segmentation

    Investing in areas that will attract the right developers is key to long-term sustainability. And there are a few key areas that will require especially close attention. First and foremost, developer segmentation will be absolutely vital for every platform. As the product landscape expands, platforms need to be clear which new developers may want to engage with their platform.

    By revisiting developer segmentation, new product use-cases can be included to ensure that content, support and messaging match what developers need. For example, if low-code/no-code developers are a new demographic, platforms need to extend content the scope of their help materials to include more basic explanations (including generic technology terms) and extra links to FAQs.

    On the other end, platforms also will need to invest in tools that match the needs of different developer groups. Experienced, full-stack developers using the latest languages and patterns will expect sophisticated tooling, services and frameworks as well as DevOps tools.

    Either way, continued focus on self-service will ensure cost-effectiveness by allowing platforms to manage extra usage without the need to apply extra resources.

    Scaling New Heights With the Cloud

    If transitioning critical services to the cloud isn’t already on the agenda for every platform business, it should be. A seamless service transition to cloud, with future-proofed expansion capabilities, is imperative for any platform that wants to engage developers. Why? Because as well as supporting service-based pricing, transitioning to the cloud facilitates scale and allows developers to access the platform securely from any location. Above anything else, a robust cloud infrastructure makes platforms more flexible, facilitates collaboration between platforms and developers and enhances the platform’s overall performance.

    Thriving With Developers in a Post-COVID World

    The time for platforms to rethink how they engage developers is now. Building a developer ecosystem will be vital for any platform wanting to scale at speed. If equipped with powerful tools, enabled through self-service and supported through effective educational resources, developers can be the difference between platforms that struggle in a post-COVID-19 world and those that thrive.

  • VMware Looks to Meld IT and Security Operations

    VMware Looks to Meld IT and Security Operations

    VMware has acquired SaltStack as part of an effort to unify IT and security operations management. The announcement was made during the online VMworld 2020 conference this week.

    SaltStack has developed an open source IT automation platform to automate IT operations. In recent months it has been extended to also address security and compliance management.

    At the same time, VMware released a bevy of updates to its security portfolio, including VMware Carbon Black Cloud Workload. That offering combines vulnerability reporting with workload hardening software for both legacy platform and microservices-based applications deployed on Kubernetes clusters. It also includes elements of AppDefense, which VMware developed to harden workloads running on VMware vSphere platforms.

    VMware also announced VMware NSX Advanced Threat Prevention, which combines NSX Distributed IDS/IPS with malware detection software and network traffic analysis (NTA) technologies acquired from Lastline Inc.

    Finally, VMware announced it has committed to reselling a secure web gateway from Menlo Security as part of the VMware SD-WAN portfolio and formed an alliance with Zscaler to manage security as a service.

    SaltStack provides VMware with an IT automation framework that can be applied across multiple clouds running virtual machines and containers. The current vRealize IT automation framework is optimized for instances of VMware vSphere.

    Tom Corn, senior vice president for the Security Business Unit for VMware, said VMware’s entire approach to security is predicated on making it easier for IT operations teams rather than cybersecurity professionals to implement security controls. There are simply not enough cybersecurity professionals available to implement cybersecurity controls when DevOps teams are rolling out and updating application workloads multiple times a week, he said.

    Cybersecurity teams will continue to define what controls will need to be put in place, but it will be left to the IT operations teams to implement those controls in much the same way responsibility for application security is now also being shifted left as part of best DevSecOps practices.

    Corn said it’s clear IT security is a team sport that requires greater collaboration among IT operations teams, developers and cybersecurity professionals. VMware has been investing in security technologies with an eye toward making it easier for IT operations teams to automate security operations in much the same way any other IT task is being automated, he noted.

    That convergence isn’t going to occur overnight. There are many challenges including culture. Many cybersecurity professionals view IT operations and developers as being equally responsible for many of the root causes of a cybersecurity breach. It may be a while before cybersecurity teams have enough confidence in the ability of IT administrators and developers to proactively address cybersecurity issues before and after applications are deployed in production environments.

    Of course, there’s no alternative. The days of waiting two months or more for a security review as part of a waterfall development process are over. Security, like it or not, needs to become as agile as the rest of IT.

  • The Importance of Digital Certificates to DevOps Teams

    The Importance of Digital Certificates to DevOps Teams

    Certificate management is an important element of ensuring DevOps processes run smoothly

    Organizations are increasingly integrating DevOps into their app development processes. According to Amazon Web Services (AWS), DevOps holds so much promise with organizations because it has the potential to increase the speed and ability to deploy new apps and services. Together, development and operations personnel use extended technology stacks and tooling to automate processes that they’ve traditionally fulfilled manually.

    Organizations want to get the most out of integrating their different teams together under a DevOps model. It’s not surprising, therefore, that DevOps is constantly changing in an attempt to fit the ever-evolving technology landscape, including IT security.

    Sid Phadkar, senior product manager at Akamai, made this point clear to TechRepublic:

    With the rising number of data breaches and increased emphasis on data privacy regulations such as PSD2 and GDPR both in the U.S. and globally, DevOps-savvy organizations will be forced to prioritize diligence in security measures overtime to market in the year ahead. As new regulations are put into place, more application developers will be mandated to build strict security policies directly within code. There will be an uptick in DevOps tools that cater to automating more compliance-related tasks within infosec teams, thus incorporating security and compliance measures into everyday CI workflows.

    The issue is that it’s not always easy to align DevOps with security. Good security practices commonly come into contact with the timely delivery of a new application or a service. Without the right tools to support DevOps, security personnel can’t support developers in a way that they need to be supported. As a result, developers will be more inclined to resist new security practices and find non-compliant alternatives to new processes that slow them down.

    These challenges are of special concern for certificate lifecycle management. Organizations need to secure the DevOps life cycle with PKI via code signing or creating a certificate. But, this implementation of PKI often suffers from poor visibility into certificate life cycles and inconsistent communication with Certificate Authorities.

    Conventional DevOps pipelines also commonly rely on manual requests to obtain trusted certificates. These types of requests undermine the agility of the software development life cycle. Most containers aren’t up for very long, so if those requests take days to complete, the resulting digital certificates will be effectively useless unless the organization slows down its delivery of applications. Such dynamism also makes it difficult for DevOps to manage and monitor those certificates on their own. Team members could therefore look for shortcuts, resort to ad hoc processes or purchase certificates that use multiple cryptographic standards—variations that increase the organization’s security risk.

    These concerns don’t resonate only with industry analysts. They’re also shared by DevOps professionals. In a 2019 survey, 74% of DevOps professionals told Venafi they were concerned that issuing certificates could slow down development. Just over a third (39%) of developers said they should be able to circumvent those policies to meet their service-level agreements, while less than half (48%) of respondents voiced their belief that developers in their organization always request certificates through channels and methods approved by the security team.

    How DevOps Teams Can Best Handle Their Certificates

    DevOps teams can best handle their certificates by automating their certificate management processes. Orchestration tools such as Kubernetes support certificate management via the ACME protocol. Kubernetes stores private keys in the Kubernetes Secret or Hashicorp Vault, thus providing seamless integration for the certificate management system. DevOps teams can also digitally sign their containers with a private CA to help verify a given container as it communicates over a TLS connection.

    Aside from automation, DevOps needs to increase the visibility of their certificates to avoid unnecessary outages. Team members need to be able to renew certificates before they expire and to address improper configurations to make sure that critical services remain up. API-driven automation can help orchestrate their processes involving keys and certificates in an attempt to balance both agility and security.

  • 5 Steps to Avoid Shadow IT Around Low-Code

    5 Steps to Avoid Shadow IT Around Low-Code

    Shadow IT is far more pervasive than most CIOs think. Cisco Systems estimates that a typical firm has 15 to 22 times more cloud applications than authorized by the IT department.

    While shadow IT solves problems in the short-term for a select few, undocumented software ultimately encourages tribal thinking and siloed departments. This can stunt reusability, slow down new developer onboarding and lead to insecure points of failure—all antitheses to a DevOps culture.

    Simultaneously, new low-code tools are emerging that promise to reduce the programming burden from developers and enable citizen developers to create business applications on their own. But what happens when advanced users know better? Perhaps they’d rather code a quick function in Python or use another framework they’re more familiar with. If not properly governed, low-code platforms could easily be circumvented and lead to shadow IT.

    As many tech leaders can attest to, enforcing companywide standards can be tricky. I recently chatted with Jay Jamison of Quick Base to see what tactics organizations should take to avoid shadow IT when introducing low-code tooling. Here are five general tips CIOs can apply to reap low-code benefits while curbing shadow IT.

    1. Earn Developer Trust

    Focus on integration and open backends to earn developer respect

    Want to win the hearts of developers? Focus on integration. Many engineers don’t care about a shiny user interface and would rather interact with data models programmatically. As I’ve covered before, open API access is the secret sauce for low-code platforms.

    Choose a low-code platform that provides high-performant and secure RESTful APIs that use JSON. With open access to data models and low-level mechanics, advanced developers will feel less inclined to subvert the platform. What’s great about HTTP APIs is that they’re agnostic, so developers can interact with them from whatever language or environment they’re comfortable with.

    2. Govern and Set Permissions

    Establish access management policies with fine-grained permissions

    To avoid the emergence of shadow IT, software leaders must apply governance over data models, users and application privileges. These permissions should be fine-grained, to the field level. To do so, managers require an application lifecycle management functionality to edit these permissions. Such a governance layer would grant “tremendous power and control to IT and the business,” said Jamison.

    On low-code governance patterns, Jamison notices companies often lean toward one of two extremes:

    1. IT-centric: IT is leading the software models and only IT users can make changes.
    2. Operation-centric: IT acts as a governance body and building is pushed into business domains.

    Selecting which model to use is often based on the organizational culture and individual team member capabilities, noted Jamison.

    3. Encourage Collaboration and Knowledge-Sharing

    Build an easy path from mock-up to production

    Companies adopt low-code tools because they require something “quick and adaptable.” Yet, getting different operating teams at the same table can be difficult. Without high-quality collaboration, low-code could introduce a bottleneck.

    “Many teams must come together,” Jamison said. “How will this be productized; how will the workflow be tracked?” Companies truly require an effective collaboration model if they are ever to regularize their data models and assign access roles.

    To get everyone on the same page, Jamison recommended starting with a mock-up everyone can use as a reference: “Create an online chart to map out workflows and stitch it together in a collaboration space.” Business strategies can create detailed plans, and then builders can transform this into a prototype.

    4. Document and Reuse

    Encourage departments to document processes and expose reusable tools

    If users are sharing documentation via Excel and email, you know something’s wrong. Undocumented software is unmanageable software. Jamison reinforced the need for a “control layer” to localize documentation and encourage platform-wide governance standards.

    “Like buildings in a cityscape, some apps are more significant than others,” Jamison said. CRM applications may be entirely purpose-built for niche settings, while others, such as a team registry application, could be reused across an entire corporation. Increasing tooling reusability, he noted, requires teaching and training of documentation and change management practices.

    5. Adopt a Platform-Based View

    Standardize on a single platform and embrace a low-code culture

    The more teams use low-code, the more they think on low-code terms. As teams become more proficient in low-code, their mindset becomes: “How can low-code solve that problem?”

    By adopting a platform-based view, low-code becomes a utility to drive consistent data flows and workflows. To achieve this, it’s probably best to standardize around a single, companywide low-code platform. Otherwise, you risk inviting more unstandardized practices.

    For example, Jamison described how a large-scale manufacturer operating hundreds of plants worldwide uses a low-code platform to audit all plants’ quality in real-time. Other traditional non-IT businesses with a global footprint could similarly return a net value from consolidation on a single low-code platform.

    Will Low-Code Increase Shadow IT?

    It’s difficult to enforce any new tool, and some users will inevitably circumvent standard processes. However, by demonstrating the benefits of shared collaboration and low-code creative potential, leaders could stem shadow IT and the adverse side effects therein.

    By talking their language and saving time, low-code tools could win developer faith and encourage platform use. In review, here are some other ways to avoid shadow IT side-stepping around low-code:

    • Show some-code: Win developer’s hearts by talking on their terms and opening up the hood.
    • Govern: Use a common data model and apply fine-grained security constraints.
    • Ignite discussion: Bring groups together for open knowledge forums.
    • Unite business and IT: Enable citizen developers to design mockups and builders to execute quickly.
    • Use the platform: With more low-code use comes more creative sparks.

    Ultimately, low-code won’t replace 100% of your programming needs (especially at software-oriented companies). Low-code should be viewed as a time-saver, not a talent replacer, Jamison said. Low-code enables developers to quickly assemble simple business applications, freeing them to devote more time to core competencies or advanced processes that are far more interesting, such as building machine learning models.

    Final Thoughts on Low-Code Transformation

    There are many forces driving the current low-code revolution. Major tech hubs lack developer talent and COVID-19 has accelerated digital disruption. In this economy, requirements for business processes are changing “by the hour,” said Jamison. “The awareness around low-code is increasing because the need for automation and more digital solutions is increasing.”

    As Jamison noted, many enterprises are undergoing a “dual-track digital transformation.” Companies are investing in expensive, broad-scope cloud technologies while still digitizing many manual processes. To Jamison, low-code is now imperative to meet both needs. Thus, it should be adopted with forethought for all potential use cases (and shadowy non-uses).

  • 3 Ways To Tackle the Operations Complexity of DevOps

    3 Ways To Tackle the Operations Complexity of DevOps

    DevOps is challenging, some of its complexity requires a platform that is both SaaS and managed environments, running on top of several cloud providers and potentially on-premises as well. Is there a platform that connects applications and systems while supporting enterprises as they accelerate their digital transformation efforts? If done the traditional way, you have all the ingredients to fall into an operations nightmare. Unless you tackle the challenges with cloud-native approach from day one.

    Let’s explore three ways to tackle the operations complexity of DevOps.

    Cloud-Native Architecture

    Why use Kubernetes? This technology is an open source system for automating deployment, dealing with massive scale and management of containerized applications. If the main initiative is to isolate every single integration that runs, then select an architecture component that could give you a head start.

    A well-designed application based on microservices and running on containers can benefit heavily from technology such as Kubernetes in the following ways:

    • Resilience & Fault Tolerance: These are key ingredients for today’s highly available, always-on systems. With the help of Liveness and Readiness probes, we can set up an environment where any misbehaving container could be automatically recycled and have a new instance ready to use.
    • Multizone Cluster: With a multizone cluster, it is possible to apply hard-to-achieve fault-tolerant architectures where a container running on a zone is automatically moved to another zone if there is a failure. By coupling that with GCP’s ability to replicate volumes across zones and you can deliver a true fault-tolerant architecture.
    • Millisecond recovery: Any restarted container takes milliseconds to get ready again, so absolutely no interruption occurs.
    • Microservice Isolation: Misbehaving containers won’t affect others as there are reinforced limits in terms of CPU and Memory usage.

    Deployment as Code

    GitOps is our mantra. GitOps is a way of implementing continuous deployment for cloud-native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and continuous deployment tools.

    The technique here is to follow regular Git Flow methodology and have automated “operators” apply changes to a Kubernetes cluster. These operators are regular containers running on a Kubernetes cluster, which constantly monitor Git source repositories for changes. Once a change is detected, the operators automatically trigger an update.

    For the automated installations, use Helm as the deployment engine. When changes are committed to the Helm configuration in Git, the operators automatically apply those changes.

    This approach essentially reverts the classical imperative deployment model where actions are performed in the environment to a declarative approach where the state of the environment is defined by a set of rules and kept in sync by these operators.

    Outstanding levels of governance can also be achieved in all clusters from a single source of truth. If a manual change was introduced in any of the environments, the operator would detect and revert back to the defined state.

    Normalize Hybrid Environments

    Kubernetes is powerful, but comes at a price. It is very challenging to maintain different versions and distributions, especially when using different cloud providers and on-premises environments. Due to that fact, you must identify a technology that would abstract the complexity away, normalizing the operation.

    Consider Google Anthos for this, which is a full Kubernetes distribution based on Google Kubernetes Engine and is available to Google Cloud Platform customers. Over the years, Google refined its Kubernetes distribution and eventually released it as a product in its cloud platform.

    Main advantages of using a technology such as Anthos include:

    • Standard Kubernetes installation for on-premises, VMware-based environments.
    • Connectors for Kubernetes Engines in AWS and Azure cloud providers.
    • Built-in configuration management capabilities allowing us to declare our clusters and keep them in-sync.
    • Remote-controlled Kubernetes environments from a single admin portal so all cluster resources are easily accessible.
    • Monitoring metrics consolidated on Google’s StackDriver.

    The three ways are more than enough to achieve greater scalability, governance and control of hybrid environments to address DevOps and complexity. They are actually a new mindset for application design and operations. I truly believe that they can help companies deliver better software while recognizing the complexity and challenges of dealing with enterprise applications.

  • 7 Things to Make DevSecOps a Reality

    7 Things to Make DevSecOps a Reality

    While talking about DevSecOps has become a hot trend, it is clear that many organizations claiming to follow such methodologies are actually mired in traditional waterfall development. Let’s figure out if you’re really ready to implement DevSecOps.

    In a world that relies heavily on distributed computing and third-party services, security is paramount for those who want to remain competitive. From open source applications to operating systems developed, deploying, delivering and correcting application vulnerabilities must occur rapidly before breaches or compromises occur.

    Here’s the good news: If your company practices authentic agile development and uses highly modular design patterns such as service-oriented architecture, you are well-positioned to achieve DevSecOps success. Why? Because you are already using key strategies that provide solid foundations for secure computing solutions, so you can immediately start experiencing the benefits that come from doing DevSecOps right.

    Follow the Exact Recipe: Don’t Cherry-Pick Ingredients

    DevSecOps emerged from people realizing that DevOps did not adequately highlight security concerns and security should be shifted farther left in the software development life cycle. You should think of DevSecOps as sweetening the existing “recipe” of DevOps by baking security in from the beginning without slowing down the development and release cycles. It may sound obvious, but increasing velocity while reducing risks will guarantee the release of better products because they are built with potential risks in mind (for instance, more and better error handling). This approach results in happier customers and repeat business, which will positively impact your bottom line.

    DevSecOps Requires a Shift in Culture and Mindset

    Let’s face it, the days of successfully deploying applications designed to meet business demands without embedding security controls early in the development life cycle are gone. Effective DevSecOps spans culture, practices and tools that break down silos, orchestrate integrated processes with automated tasks and simplifies security by bringing it out into the open. Instead of “security through obscurity,” boundaries and channels are clearly defined and narrowly focused.

    The benefits of DevSecOps are many and include:

    • Automating security review and application testing.
    • Increasing the speed of delivery enhances product quality.
    • Enhancing compliance with continuous monitoring and auditing.
    • Fostering transparent and open cultures.
    • Reducing costs, development church and application attacks.
    • Delivering increased security and confidence.

    A methodology that uses communication and collaboration to allow for dynamic development and deployment is crucial for responding to change and needs rapidly. When done right, this new mindset will make everyone in your organization accountable for security with a simultaneous mind and talent shift.

    Putting DevSecOps Into Practice: A Checklist

    An efficient DevSecOps program will require continuous management and developer education and process improvement through open collaboration, proactive monitoring and informed feedback. Here’s a short checklist to ensure you’re on the right path.

    1. Build an Environment Conducive to DevSecOps: Engage leaders with a new mentality that makes it incumbent on leadership to understand engineering practices, so they know when things need shorting up. Deeply integrate management, so they support the necessary investments in tools and training while encouraging teams throughout the entire development life cycle.
    2. Ensure Open Communication and Active Training: Promote collaboration and ongoing learning that leads to continuous improvement across the organization. Do this well by providing developers with the training and tools they need. Enable failing fast, early and often so you learn from it and create something useful.
    3. Adopt a Security-Conscious Culture: The driving force behind DevSecOps requires security to be defined at the beginning of a project for repeatable, consistent use. This practice will help you respond to security needs and changes quickly while increasing team collaboration.
    4. Implement Infrastructure as Code (IaC): Without relying on manual processes, IaC helps manage and provision infrastructure automatically. This approach allows code to automatically be rolled out in a repeatable and consistent manner through a version-control system instead of relying on installation gurus and “component owners.”
    5. Use Genuine Agile: Instead of cherry-picking from the agile approach and using your own form of agile-flavored waterfall—focus on practicing “Pure Agile.” This method includes detailed and frequent stakeholder involvement, “fail fast” practices and processes, a “meet the requirements” values and principles mindset and technical excellence.
    6. Adhere to Modular Design Patterns Closely: While object-oriented design (OOD) and service-oriented architecture (SOA) mean different things to different people, the commonly understood key is decomposing large business problems into small business problems that can be addressed by discrete services through boundaryless information-flow sharing.  When done correctly, OOD and SOA will help your applications scale quickly while decreasing costs.
    7. Favor Resource Management over Pride of Ownership:  There is a now-famous analogy about thinking of software components more like cattle than like pets.  While grim, the point is a salient one: When something fails, you should be able to quickly replace it with a new or improved component instead of trying to nurse the ailing component back to health. This mindset better promotes modularity and discreteness of purpose, which, in turn, leads to faster fix and restoration times.

    As virtual environments and cloud usage grow, the need for DevSecOps to be done “the right way” is growing right along with it. But the sense of urgency to implement DevSecOps practices “the right way” hasn’t quite caught up yet. The challenge is to embrace all aspects of DevSecOps day in and day out, instead of just going through the motions of the select practices you adopted.

    The call to action is clear: Now is the time for organizations to move the speed of delivery and secure code out of the textbooks and manifestos into the mainstream.