Category: Features

  • Tips For Standardizing API Life Cycle Management

    Tips For Standardizing API Life Cycle Management

    Software life cycle management is becoming more critical for today’s technology-fueled organizations—because you can’t just release software into the world and expect it to work perfectly for years to come. More often than not, development teams must constantly adapt their software, progressively add features and cater to new use cases as they arise. This is nothing new for web APIs, which are prone to continual evolution and whose integrations require regular upkeep to avoid breaking changes.

    As such, the discipline of API life cycle management has gathered steam. This concept focuses not only on the design and development of APIs, but on the entire life cycle, including testing, monitoring, documentation, maintenance, versioning, CI/CD and even deprecation. Localizing a strategy for API life cycle management from the get-go can increase the longevity and usability of a platform. It also helps software providers treat their APIs as an iterable product rather than a one-and-done offshoot of a digital platform.

    I recently met with Rakshith Rao, co-founder and CEO of APIwiz, to gather insights on standardizing API management across an organization. According to Rao, there are many ways to implement governance to make these interfaces more consistent. For example, automated security analysis, contract-driven development and implementing style guides are just a few ways to wrangle an increasingly extensive API portfolio. Below, we’ll review these tips and others to consider how to best manage API life cycles, hopefully, before sprawl sets in.

    Four Tips to Increase API Governance

    Medium-to-large organizations might be handling thousands of APIs, said Rao. This new paradigm brings many opportunities for digital transformation, but it can also be a nightmare to manage. Too often, APIs aren’t built with tangible business requirements taking center stage.

    Many of these initiatives didn’t begin with consistent policies from the get-go. For example, it’s also easy to skip out on documenting internal services. But, fractured practices harm discovery and reusability. To rectify this issue, Rao shared many ways in which technical leads can promote better API hygiene.

    Enable Visibility of API Usage With API Monitoring

    The API life cycle spans stages of design, deployment, deprecation and eventual retirement. And throughout this life cycle, developers will likely release new versions of the same service. But although you want consumers to adopt the latest version, some large organizations must support legacy versions for years to come, explained Rao. As a result, different API versions are often developed and run simultaneously by various internal or partner teams. Sometimes, “no one turned the tap off and the water’s still running,” he said.

    To enhance visibility for all active (and non-active) sessions, it’s important to conduct ongoing monitoring. This will help discover individual client usage patterns and help avoid shadow or zombie APIs from forming. These forgotten endpoints could pose security vulnerabilities, said Rao, as you might not enforce best practices on older versions if you don’t know they exist.

    Automate Security Analysis to Capture Vulnerabilities at the Design Level

    Not having consistency between APIs could pose data compliance issues. One method to avoid errors is to conduct design reviews on an ongoing basis, and to automate this security analysis at the design level, said Rao. Perhaps authentication tokens need to be encoded, logging requests aren’t coming in, or payloads are structured incorrectly. Whatever the case, having a complete checklist to scan and performing ongoing security analysis early on to catch these inconsistencies can be a big boon to overall governance and long-term cybersecurity.

    Adopt Style Guides but Allow for Flexibility

    Very simple data modeling errors could severely impact a system, said Rao. Thus, it’s in an organization’s best interest to use standard taxonomies and ensure data governance is an overall aspect of life cycle management. One way to ensure consistency is by using specification-driven development—OpenAPI is a common standard for this need.

    Rao also suggested developing API design style guidelines but admitted that these guides become challenging to enforce and limit as an organization scales. This is because various teams in different departments will have different API needs and often design their interfaces for various front-end requirements. His takeaway is to centralize practices but take a GUI approach to configuring and sharing them. This way, API style can be “minimally intrusive but uniformly enforced.”

    Use an Abstraction Layer for Multi-Cloud

    A full 98% percent of enterprises are using at least two cloud infrastructure providers, according to a recent Oracle report. Nearly everyone is adopting a multi-cloud strategy, but this new reality brings novel pressures for DevOps, especially when overseeing the deployment of APIs across different cloud platforms. An API life cycle management platform decoupled from these CSPs could help wrangle polyglot deployments.

    Sticky Notes Aren’t Enough for API Management

    API life cycle management goes well beyond the development and runtime phase. And as more API-first development occurs within organizations, maintaining standard interfaces will naturally require more effort. Rao also advocates for increased infrastructure automation and low-code solutions to meet these new challenges. Automating various parts of the API life cycle so there is less manual work “helps to bring down the guesswork of ensuring reliability when you release an API,” said Rao.

    We’re seeing some enterprises move from supporting hundreds to thousands of APIs. In this new paradigm, “API sprawl is imminent,” said Rao. As such, it will become virtually impossible to manually keep these interfaces in line, understating the need for more automation. Especially during times of economic uncertainty and leanness in the tech market, the democratization of such API management automation will be vital in helping organizations move faster.

    Having broken pieces of information and scattered API contracts will lead to a messy and potentially insecure adoption. As such, API management can no longer be done using sticky notes on the edge of a computer screen, said Rao. Taking the guesswork out, centralizing common policies and shifting more legwork behind the scenes will be required to avoid a splintered portfolio of services.

  • Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Denis Pushkarev is fed up with core-js freeloaders, and hundreds more malicious packages found at PyPI. (more…)

  • Technical Debt is a Major Threat to Innovation

    Technical Debt is a Major Threat to Innovation

    A survey published today suggested that technical debt is starting to take a heavier toll as IT environments continue to become more complex to manage.

    The survey of 400 IT leaders at organizations with 1,500 employees was conducted by Foundry, the market research arm of International Data Group (IDG) on behalf of Insight Enterprises, a provider of IT services. The survey found that 86% of respondents reported their organization was impacted by technical debt over the past 12 months, with the top areas affected being the ability to innovate (43%), meet service level agreements (41%) and avoid downtime (37%).

    Technical debt is created when organizations cut corners and leave known bugs in the race to meet application delivery deadlines. Application code is often not as thoroughly tested as it should be. In some cases, it turns out that what was intended to be a minimum viable product doesn’t scale all that well. Quick fixes needed to improve performance are also frequently undocumented. Inefficient code also winds up consuming more IT infrastructure than required, which adversely impacts everything from cloud costs to the amount of carbon generated.

    Juan Orlandini, chief architect for the Cloud + Data Center Transformation (CDCT) division of Insight Enterprises, said every organization struggles with technical debt; it will never be eliminated, but it does need to be contained, he added.

    The challenge is instead of trying to keep the proverbial IT lights on during the COVID-19 era, IT teams are now being asked to innovate to advance digital business transformation initiatives, said Orlandini. A full 87% of survey respondents cited modernizing critical applications as a key success driver.

    As a result, many organizations are embracing platform engineering to bring more structure to their DevOps processes, he noted. The challenge, however, is striking a balance between a more centralized approach to DevOps and maintaining the ability of developers to innovate, said Orlandini.

    The issue, of course, is that in addition to massive technical debt, the latest generation of applications are more distributed than ever. The survey found 91% of respondents now rely on multiple public cloud providers for different workloads, with 54% of data residing on a public cloud. However, the survey also found on-premises IT environments are still relevant, with 20% planning to repatriate select public cloud workloads to an on-premises model over the next 12 months.

    Nearly three-quarters (72%) of respondents also noted data volumes are growing faster than their ability to manage them, with 64% ranking implementation of a data governance program to improve data management as their top data-related objective this year. Just over a third (35%) of the data estate is now, on average, driven by edge workloads, with 29% of respondents reporting that at least 50% of data volumes now reside on the edge. Nearly two-thirds (64%) expected that to increase in the next 12 months.

    A total of 85% of respondents also indicated their organization is using artificial intelligence (AI) to some degree to drive business insights and/or efficiencies, although only 36% reported having optimized their use of AI and machine learning (ML) across the enterprise.

    Finally, cybersecurity also remains problematic, with 51% reporting they were impacted by a cybersecurity breach over the past 12 months. Just 20% resolved their issue in one day, while 31% needed less than a week. Nearly half (49%) required one week or more to recover.

    It’s clear that IT isn’t becoming any easier to manage. IT teams need to find ways to build and deploy new applications while reducing technical debt so it doesn’t strangle future innovation.

  • Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

    Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

    Fiberplane today announced it is extending the reach of a real-time collaboration notebook designed for DevOps teams by making available tools for building plug-ins based on the WebAssembly (Wasm) framework.

    Micha Hernandez van Leuffen, Fiberplane CEO, said these plug-ins, dubbed providers, will make it much simpler for anyone to connect the Fiberplane notebook to other DevOps tools and platforms.

    The Fiberplane notebook uses the same operational transformation algorithm used in Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly. That approach enables a DevOps team to, for example, write and run PromQL queries and display Prometheus charts alongside other data presented via an integrated graph. Wasm makes it possible to run those providers both in the browser and on a backend platform.

    Fiberplane also announced it is open sourcing its Provider Development Kit (PDK), written in Rust, to enable organizations or third-party developers to create additional plug-ins. A Fiberplane Daemon then executes the plug-ins. The overall goal is to provide an open format based on Wasm for consuming DevOps data, noted Hernandez van Leuffen.

    The full open source Fiberplane WebAssembly-based Plugin System includes a Fp-bindgen to provide the bindings generator for building plug-ins, the Provider Development Kit (PDK), a toolchain for building plug-ins, a set of pre-configured plug-ins for Prometheus, ElasticSearch, Sentry, Grafana Loki, Cloudwatch and a generic HTTP provider, the Fiberplane command line interface and the Fiberplane Daemon.

    Fiberplane is essentially taking the concept of notebooks used for collaboration by data science teams and applying it to DevOps workflows. The goal is to improve DevOps teams’ productivity by reducing the amount of time it takes to sort through multiple types and classes of DevOps data to resolve an issue.

    As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues now invariably spans the responsibilities of multiple members of an IT team. Fiberplane, in effect, makes it possible to spin up a virtual war room that enables the members of an IT organization to collaborate until the issue of the moment is resolved.

    The speed at which any IT issue is resolved has become a crucial metric. Given the complexity of IT environments, it’s inevitable that incidents will arise. Ideally, IT teams would discover those issues before they disrupt the business. However, in reality, the metrics organizations use to evaluate the effectiveness of a DevOps team are often how quickly IT issues are resolved once they are discovered. The longer it takes for a distributed DevOps team to marshal its resources, the more likely it becomes that team will be perceived as being inefficient—regardless of what level of application availability is actually achieved.

    Most DevOps teams have, of course, implemented a wide range of incident management best practices that create a level of muscle memory for responding to a wide range of issues. The trouble is there will always be unforeseen issues that arise. DevOps teams, as a result, need to find ways to quickly focus on an unpredictable issue that they didn’t anticipate.

  • More Java Apps Are Migrating to the Cloud

    More Java Apps Are Migrating to the Cloud

    A survey of 879 enterprise developers and architects from Vaadin, a provider of framework for building Java applications, found that, as part of modernization efforts, the pace at which Java applications are moving to the cloud is now accelerating.

    The survey found more than one-third (36%) of Java applications are already deployed in the public cloud. More than half of respondents (56%) are also already deploying some of their Java applications into Kubernetes or serverless environments. Nearly two-thirds (63%) said they planned to move more Java applications to the cloud over the next 24 months, the survey also found.

    Kim Weins, vice president of product and marketing at Vaadin, said the survey makes it clear that enterprise IT organizations are still highly committed to Java. Still, there is a clear shift underway in terms of where those applications are being deployed. More than a third of respondents (35%) said they have Java applications deployed on Amazon Web Services (AWS), while 22% have deployed them on the Microsoft Azure Cloud. Another 11% are running them on the Google cloud platform.

    This shift, however, will take time. Almost half (47%) of Java applications still need modernization. As a result, 63% of respondents planned to increase their investments in modernizing existing Java applications.

    Maintainability is the top-ranked motivation for modernizing Java applications (32%), followed by security (20%) and ongoing maintenance costs (10%), the survey found.

    The top three challenges in developing Java applications are building an intuitive and simple user interface (81%), upgrading the tech stack (81%) and ensuring app security (78%).

    There is also a shift underway in terms of the frameworks used to build and modernize applications using a more cloud-native approach. A full 70% of respondents use Spring today, but 50% also noted they are planning to increase their use of Spring Boot. Other Java frameworks used include Vaadin Flow, Quarkus, Hilla and React. While derivatives of Spring are the dominant framework, it appeared more organizations are at least evaluating other options, noted Weins.

    Most organizations are also integrating Java applications with modern tools for logging (72%), observability (61%) and single sign-on (53%), the survey found.

    The shift to Java 17 is also well underway, with nearly three-quarters of respondents (73%) using or planning to use it over the next year. More than a quarter (26%) are already on Java 17 or a later release. Another 21% are currently upgrading, while 26% plan to update in the next 12 months.

    Overall, the survey found Java is being widely used for both internal (64%) and customer-facing (62%) applications. Java is most often used to build full-stack Java apps (70%) and backends (69%), the survey found

    Finally, the survey found more than a third of respondents (38%) expected that finding and retaining developers would be a significant challenge in 2023.

    There are, of course, no shortage of options when it comes to deploying Java applications. Most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a venerable programming language that itself has been modernized.

  • Quali Update Strengthens Infrastructure Security

    Quali Update Strengthens Infrastructure Security

    Quali today announced enhancements to its Torque automated infrastructure platform to add support for security scans and Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    OPA enables organizations to implement cybersecurity policies as code. The challenge many organizations have encountered is that not many developers have mastered the programming language required to implement OPA. Quali is embedding OPA in a platform that enables IT teams to implement it using a graphical tool that enables central management and application of those policies.

    David Ben Shabat, vice president of research and development at Quali, said the overall goal is to implement scans and policies in a way that reduces the number of misconfigurations that are made when organizations provision infrastructure-as-code (IaC).

    As part of that effort, Torque now flags any policies that fail validation. In addition, administrators can pick and choose which OPA policies to import, including both out-of-the-box and existing custom policies. Those policies then enable Torque to automate approvals or denials of deployments based on compliance with those policies after scans and other health checks have been run.

    Quali has been making a case for policy-based triggers for cost controls, automated start-up, shut down and pausing of IT environments to give IT teams more control over infrastructure using a software-as-a-service (SaaS) platform. That approach enables IT teams to provide a set of guardrails for provisioning infrastructure that prevent mistakes from being made, noted Ben Shabat. Those controls can be applied using the graphical tool Quali provides or programmatically via an application programming interface (API) that Quali exposes, noted Ben Shabat.

    It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that allows for central application of policies that act as guardrails to prevent developers from making these types of mistakes as an alternative to scripts created using tools such as Terraform. That approach also provides more visibility into how infrastructure resources are being consumed.

    Every minute a developer spends managing infrastructure is one less minute they could be spending writing code. As application environments become more complex, it is becoming more challenging for developers to manage infrastructure-as-code. The issue is that DevOps teams who could provision infrastructure for developers are overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, leading to more mistakes.

    It’s not clear whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t require developers to have as much infrastructure expertise. However, as organizations look to lock down software supply chains, the way infrastructure is provisioned using code will, in many cases, need to be reconsidered within the context of a larger DevSecOps workflow.

  • Organizations Prioritizing Java Application Modernization

    Organizations Prioritizing Java Application Modernization

    A survey found that modernizing existing Java applications is a higher priority than other projects for 87% of respondents, with more than 80% of these applications expected to be re-engineered over the next five years. The survey polled 450 IT professionals working in organizations in the U.S. and United Kingdom that have more than 500 employees.

    Conducted by the market research firm Vanson Bourne on behalf of Diffblue, a provider of a generative artificial intelligence (AI) platform for refactoring applications and generating unit tests, the survey also found enterprises plan to invest nearly half (45%) of their software development resources on modernization of existing applications versus developing new ones. A full 90% of respondents expected to rely on automation to accomplish those tasks, the survey found.

    Specifically, survey respondents reported they planned to rely on automation to improve security (50%), increase development velocity (45%) and improve developer experience (42%). Well over half of respondents (58%) said they had already been working on these projects for more than 12 months.

    If organizations don’t modernize Java applications, more than half of respondents (51%) said too much time would be spent on unproductive coding, while 50% said development velocity would be adversely affected. The biggest obstacles cited are choosing the right technical approach (45%) and securing budget (42%).

    More than half of organizations (59%) have created a dedicated modernization budget to support their efforts. Nealy half (48%) said funds are being provided by business teams for projects, while 49% said general operating budgets have increased.

    Diffblue CEO Matthew Lodge said it’s clear there is a huge commitment to application modernization. The reality is the majority of work IT teams do involves applications that have already been deployed. The challenge they face is that the effort required to modernize these applications is still far too dependent on manual processes, he added.

    Overall, the survey found 96% of respondents considered Java applications extremely or very important to their organizations. On average, 65% reported additional Java applications are still being developed. Only 4% said they planned to migrate away from Java as part of a modernization effort.

    Over half of the respondents expected to use Java 11 (53%) or Java 17 (56%) in their applications, compared to 19% using Java 8. More than a quarter (27%) expected to use a forthcoming Java 21 release. A full 100% expected to use the Spring framework to build these applications, with more than half (54%) planning to upgrade to the latest version that supports Java 17. A full 97% said unit testing is an “extremely” or “very important” element of their application modernization effort.

    After experiencing something akin to a mid-life crisis, Java has itself been modernized with the release of Java 17, noted Lodge. The Java community is now adopting many concepts that may have been pioneered in other programming languages, he added.

    Regardless of whether organizations are modernizing existing Java applications or writing new ones, the one thing that appears certain is the venerable programming language isn’t about to disappear any time soon.

  • DevOps Done Right: How to Succeed in DevOps From Day One

    DevOps Done Right: How to Succeed in DevOps From Day One

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

    You’ll learn:

    • DevOps best practices, processes and the tools you’ll need
    • Tips and tricks from experienced practitioners sharing their real-world experiences
    • The basics of DevOps
    • How to choose the right technologies
    • Common challenges and how to overcome them
    • The benefits of DevOps as a methodology and a career
    • And more!

    As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

    DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

    That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

    DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

    At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

    One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

    DevOps Onramp Virtual Summit - Submit your talk

    If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.

  • Understanding the Infrastructure Automation Maturity Model

    Understanding the Infrastructure Automation Maturity Model

    Nearly every company wants to evolve its digital transformation and increase the pace of software delivery and operations. And infrastructure automation is a new means to achieve these ends. It supports the emerging discipline of platform engineering and can increase scalability and reactivity to unforeseen events, enabling software ecosystems to be more anti-fragile. Increased infrastructure automation also helps free up engineers from focusing too much on managing DevOps when they really should be building out new features.

    But introducing more infrastructure abstraction can be met with certain challenges. This is often because departments have a wide range of cultures, processes and tooling already in place. With varying maturity levels across teams, it can be challenging to gauge where a company is before attempting to introduce new automation across the board. And as further evolution may require significant changes, having a baseline is key to planning for the future.

    I recently chatted with David Williams, senior vice president of market strategy at Quali, about an internal technique they’ve been using at Quali to gauge the maturity of their clients’ infrastructure automation. Their infrastructure automation maturity model breaks down the journey into four unique stages, moving from the least-mature ad-hoc automation to the most-mature autonomous solutions. Below, we’ll review this model and consider what questions need to be asked to ascertain where your team sits on the spectrum. We’ll see how enterprises can leverage such a model to hone in on improving their software operations.

    Four Questions to Determine Infrastructure Maturity

    DevOps is still a wild west in terms of how people approach it, said Williams. So before attempting to mandate sweeping cultural changes, it helps to first determine the base level of DevOps maturity within an organization. Here are four questions that can quickly assess the state of infrastructure automation within an organization.

    1. What Culture Already Exists?

    First, it’s good to evaluate the culture that already exists. How do teams deliver value and how is this value measured? Perhaps throughput or code quality is measured with specific metrics or SLAs. Understanding the DevOps attitude (and aptitude) within the organization will highlight pre-existing capabilities and show how teams collaborate.

    2. How Are People Organized?

    The genetic makeup of teams can dictate much about development and operations. How are teams organized? Are they large, siloed teams? Or are they two-pizza-sized teams? Understanding team organization and communication patterns are necessary to identify bottlenecks.

    3. What Processes Are Already in Place?

    Next, consider the development timelines and procedures already established and in use. Are teams applying SAFe, Lean, Agile or Scrum methodologies? What are these exact processes and how mature are they? Answers to these questions will demonstrate general release cadences and how teams drive productization.

    4. What Infrastructure Automation is Already Being Used?

    Lastly, you’ll need a window into what level of infrastructure automation, if any, is already in use today. How is it delivered? How is it managed? How is the success of this automation measured, and what is the overall outcome? You will likely find that automation is typically quite siloed and teams have differing approaches. This auditing is vital to identify what works well and what doesn’t.

    The Four Levels of the Infrastructure Automation Maturity Model

    Asking the above questions will quickly determine an organization’s “readiness state,” said Williams. But how do these answers map to the overall maturity of the organization’s infrastructure automation? Well, he shared four basic levels of infrastructure automation maturity that are commonly found in practice throughout today’s software development environments, ranging from bespoke scripts to more robust self-defining automation.

    Level 1: Ad-hoc

    The most basic level of infrastructure automation is ad-hoc integrations involving a mix of old and new technology. This level is chaotic and fragmented, with varying processes used throughout the organization. These bespoke integrations and scripts also may not have excellent visibility, limiting the potential for reusability within an organization.

    Level 2: Automation

    Next is having automation that is specifically tied to a certain technology stack. Nowadays, organizations are commonly hybrid multi-cloud, having adopted automation piecemeal with each new stack. This often results in multiple silos of automation stacks that are blind to each other. At this maturity level, one automation might fire off another automated procedure and so on, but engineers aren’t 100% aware of how they influence each other.

    Level 3: Frictionless

    The next level of infrastructure maturity begins to take the reins with more intentional automation adoption. At this stage, organizations embrace an internal developer platform, similar to Spotify’s Backstage, that helps engineers deliver and manage infrastructure more seamlessly. This tooling is more advanced than other levels integrating key commands into the developer’s IDE. Doing so eliminates the need to switch between environments and reduces friction.

    Level 4: Self-Defining

    Finally, the most advanced form of automation involves deeper intelligence within application operations, including the ability to dynamically optimize infrastructure. At this stage, infrastructure is self-defining, meaning production applications can automatically adapt, be self-governed and enable bursting and non-bursting capabilities. Such intelligence is typically proprietary to cloud providers, said Williams, yet companies often desire this intelligence inherent at the application level. Williams describes this stage as the “intelligent allocation of resources in line with application life cycle requirements.”

    Benefits of Self-Defining Infrastructure Automation

    Self-defining infrastructure automation has many benefits for companies, including having the infrastructure in line with application needs, scalability and measuring usage to optimize cloud spending. Many points within the software development life cycle could warrant increased automation, such as infrastructure-as-code (IaC), deployment release engines, configuration, traffic scalability, cloud management, containerization and documentation. But it’s not until you open conversations around infrastructure automation maturity and understand who is responsible for managing it that you can hone in on what areas can be improved.

  • Akamai Makes Case For Next Era of Cloud Computing

    Akamai Makes Case For Next Era of Cloud Computing

    Akamai Technologies today unveiled a cloud computing service that combines its ability to deploy applications at the edge with the cloud platform it gained via its acquisition of Linode.

    Shawn Michels, vice president of product management for compute and apps at Akamai, said Akamai Connected Cloud will provide the foundation for running a new generation of modern applications that require access to both core infrastructure resources in the cloud alongside highly distributed edge computing services.

    As part of the effort to deliver that combination of services, in the second quarter Akamai is adding three sites in the U.S. to the 11 it already provides. In addition, Akamai revealed it had identified 10 additional cloud sites and 50 distributed edge computing sites that it will add throughout the rest of this year.

    As a long-time provider of a content delivery network, Akamai manages a massive distributed computing environment that spans 4,100 locations across 135 countries. The acquisition of Linode added a set of cloud computing services that enable Akamai to offer the same set of services, including CDN services, as cloud service providers.

    Akamai is now signaling it will compete more aggressively by discounting the egress fees charged whenever data is moved off a cloud platform. One of the most expensive and unpredictable costs is the egress fees cloud service providers charge whenever data is moved off their platforms, noted Michels.

    Finally, Akamai also revealed it has achieved ISO, SOC2 and HIPAA standards compliance for its services.

    Akamai is making a case for an alternative approach to cloud computing that it said will be optimized for both existing monolithic applications running on virtual machines and cloud-native applications based on containers and serverless computing frameworks. A recent survey of 458 development professionals, managers and senior leaders conducted by Techstrong Research, a sister entity of DevOps.com, found 43% of respondents are considering adding additional cloud service providers in the next 12 months. Nearly two-thirds said they are at least considering, evaluating or are ready to buy from a trusted alternative cloud vendor, with 20% reporting they have already contracted with one.

    It’s not clear whether IT organizations might actually migrate existing applications from one cloud service provider to another. At the very least, Akamai expects that as new applications are developed, the company will be able to gain a larger share of the overall market.

    There’s no doubt that a new era of cloud computing is dawning as organizations look to deploy distributed applications that process and analyze data closer to the point where it is created and consumed. These applications will then share the results of the data processed at the edge with, for example, centralized data lakes that make it possible to analyze data collected across a distributed computing environment.

    The one thing DevOps teams can count on is that as this next era of cloud computing evolves, the management of IT environments will become much more challenging for all concerned.