devopsy.kinsta.cloud

Author: Mike Vizard

  • Morpheus Data Adds Midmarket Edition of Hybrid Cloud Platform

    Morpheus Data Adds Midmarket Edition of Hybrid Cloud Platform

    Morpheus Data announced today it is adding a more turnkey edition of its hybrid cloud platform aimed at midmarket IT organizations.

    Priced starting at $16,000, Morpheus Essentials can be deployed on VMware, Nutanix, Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), with support for Kubernetes planned.

    At the same time, Morpheus Data is updating its core platform to add support for a Plug-in Framework that provides integrations with nearly 100 cloud services without requiring DevOps teams to write code. The company is also adding support for a shopping cart capability through which third-party applications can be automatically deployed as a service.

    Finally, Morpheus Data is adding scanning tools based on the security content automation protocol (SCAP) to make it easier to embrace best DevSecOps practices.

    Brad Parks, chief marketing officer for Morpheus Data, said the goal is to reduce the level of friction IT organizations encounter when trying to centralize the management of public clouds and on-premises IT environments. With more organizations than ever now managing two or more clouds alongside an on-premises IT environment, the need to unify the management of those platforms has become more pressing, he noted.

    The current state of the economy requires IT organizations to reduce the number of management consoles they need to master for each platform, which Parks noted reduces the cost of IT labor because organizations no longer need to designate a specialist to manage each platform employed. The Morpheus platform also enables IT organizations to set up guardrails that enable DevOps teams to self-service their own requirements regardless of platform within the context of policies defined by IT operations teams, he added.

    Of course, the Morpheus Essentials edition of the hybrid cloud platform might also appeal to smaller units within larger IT organizations that need to manage a range of platforms that as yet may not be as widely employed as the platform the rest of the enterprise has standardized on.

    It’s not clear to what degree IT organizations may finally be moving to centralize the management of IT just yet, but the rise of edge computing may finally force the issue at a time when most IT teams continue to work from home to help combat the spread of the COVID-19 pandemic.

    Nevertheless, IT teams are prone to be protective of their individual fiefdoms. As such, convincing them to give up a specific platform console in favor of a platform that can be applied more widely can be a challenge. There always will be a trade-off between the capabilities available in a management console that was created for a specific platform and a management console designed for multiple platforms. The issue IT leaders will need to determine is to what degree a missing capability might have a meaningful impact on the productivity of the IT team.

    Regardless of the platform selected, the one thing that is clear is as IT becomes more complex to manage the current status quo is not likely to hold.

  • Split Allies With AWS to Advance Feature Flagging Adoption

    Split Allies With AWS to Advance Feature Flagging Adoption

    Split today announced it has integrated its namesake platform for managing feature flagging with the Amazon’s Simple Storage Service (Amazon S3) as part of an effort to streamline the process of adding new capabilities to applications.

    Company CTO Pato Echagüe said one of the most challenging aspects of feature flagging is providing a way for development teams to access data required to test those capabilities. Integration with Amazon S3 will now make it possible for Split to ingest millions of customer events per minute as Parquet files from Amazon S3.

    That capability will make it possible to have enough statistically relevant data to analyze how a feature is being employed within minutes, said Echagüe. Previously, software engineers would have had to spend hours manually configuring the Split feature flag management platform to ingest gigabytes or terabytes of data, he noted. The integration with Amazon S3 makes it possible to now analyze terabytes of data in near real-time.

    Split next year also plans to make it possible to send feature flag data to Amazon S3, where it can be combined with other types of data that could be analyzed using a third-party application.

    The end goal is to make it easier for product and engineering teams to collaboratively iterate new features and capabilities faster in a way that aligns better with a product road map, added Echagüe.

    Interest in feature flagging has been on the rise as organizations invest in digital business transformation initiatives to better engage end users that are working from home to combat the spread of the COVID-19 pandemic. Feature flagging capabilities make it easier for those organizations to test new capabilities without having to expose every ens user to a capability that ultimately may not have enough appeal to be included in the application.

    Feature flagging, of course, is already employed within many DevOps workflows. Split, however, is providing a platform that is designed to make it easier for DevOps teams and application owners to collaborate on the rollout of features based on feedback from end users regardless of what DevOps platforms application development teams are employing, said Echagüe.

    As IT becomes more complex, Echagüe noted it’s more important than ever for organizations to have a consistent approach to change management. The bulk of issues many IT organizations wind up addressing usually have something to do with a recent change to an application, he said.

    There’s no doubt that as organizations begin to rely more on digital processes, organizations will want to have more confidence in the capabilities being added to these platforms. As a result, many application owners who don’t have a lot experience working within the context of a DevOps workflow still want to be able to exercise and maintain control over what features are added to an application.

    Regardless of the approach to feature flagging, it should be apparent to all involved by now that this capability going forward is going to play a much larger role in application development and deployment.

  • LinearB Looks to Automate DevOps Project Management

    LinearB Looks to Automate DevOps Project Management

    LinearB today unveiled a namesake tool that automatically constructs and visualizes detailed progress timelines without requiring DevOps teams to rekey data into a separate project management application.

    Company CEO Ori Keren said the issue DevOps teams find most frustrating when it comes to managing software development projects is collecting the data that’s required to track the progress of any given project when much of that data already resides in the DevOps tools being employed. LinearB automates the collection and display of that data that DevOps teams previously spent hours collecting, he said.

    That approach makes it easier to then identify which teams and projects need additional help in near real-time using metrics surfaced in dashboards provided by LinearB, Keren noted, adding metrics such as the tracking of cycle times also make it easier for DevOps leaders to justify those investments to business executives.

    Keren said DevOps leaders also gain better insights in how DevOps teams are actually functioning in a way that makes it easier to predict and eliminate project delays, remediate high-risk code before it is included in a production environment, eliminate bottlenecks and make certain the focus of the DevOps team remains on tasks of the highest priority.

    LinearB is making use of the application programming interfaces (APIs) that DevOps tools expose to gather the metadata that exists about the status of any given project. LinearB then employs machine learning algorithms to construct and correlate that data to give DevOps leaders more accurate insights into the status a project when compared to a project management application that requires data to be entered manually. Given the rate at which application development projects are now updated, much of the data in a project management application is outdated shortly after its entered.

    Project managers also often spend a significant amount of time trying to encourage various members of a DevOps teams to update the data that resides in those project management applications.

    At a time when many members of those DevOps teams are now working from home to combat the spread of the COVID-19 pandemic, Keren noted that manually collecting that data has never been more problematic.

    While many DevOps teams are embracing value stream management tools to optimize DevOps workflow, Keren added most of those tools do not collect data at a granular enough level to provide DevOps leaders with enough software deliver intelligence to meaningfully impact DevOps workflows in near real-time.

    In general, Keren said most DevOps teams are too focused on metrics such as the number of lines of code or the number of commits being made. Metrics such as cycle times are more indicative of the productivity of a DevOps team.

    It’s not clear how the ability to automatically pull metrics from DevOps tools might impact the role of project managers. In theory at least, they should be able to spend more time helping DevOps leaders identify issues proactively versus badgering DevOps teams to fill out reports.

    Regardless of how the role of the project manager evolves, the one thing that is for certain is most members of a DevOps team would happily prefer to see as much of that process become automated as possible.

  • SAP Makes Available Free Cloud Tier to Build Applications

    SAP Makes Available Free Cloud Tier to Build Applications

    SAP announced that next year it will make available a free tier on SAP Cloud Platform for developers that are building applications.

    Announced at the SAP Tech-Ed conference, the free tier comes at a time when SAP is encouraging developers to use its applications as a foundation for digital business process transformation initiatives.

    As part of that effort, SAP is also extending the capabilities of the low-code tools it makes available to customize SAP Cloud Platform Workflow Management and SAP Intelligent Robotic Process Automation (RPA) 2.0 to make it easier to integrate these offerings with other applications. SAP beginning in January is also promised to include a limited edition of SAP Intelligent RPA in every SAP S/4HANA Cloud subscription.

    Finally, SAP is beta testing SAP Ruum, a set of no-code tools it plans to make available alongside the low-code tools it already includes in its portfolio of tools for building custom applications that extend the packaged applications it provides on-premises and in the cloud.

    At the heart of the SAP digital business transformation strategy is SAP Business Technology Platform, which makes it possible to share data across SAP applications via a common data and object model. SAP makes available SAP Cloud Platform to provide a distinct platform-as-a-service (PaaS) environment through which developers can build extensions to its applications.

    Most recently, SAP has made SAP Graph tools in beta offering as a complement to a revamped SAP API Business Hub that will be available in beta this month.

    Thomas Grassl, vice president and global head of developer relations and community for SAP, said the company is also embracing continuous integration/continuous delivery (CI/CD) platforms as it continues to encourage developers to move away from waterfall-based approaches to building and deploying applications.

    The free tier of resources SAP is providing developers will encourage organizations to experiment more at a time when many organizations are now quite certain what digital process may ultimately gain traction with their end customers and suppliers. SAP is also focusing on no-code and low-code tools to enable organizations to accelerate the development of those applications. SAP already has an existing partnership in place with Mendix, a unit of Siemens, to make available low-code tools.

    SAP’s biggest concern, of course, is that digital business transformation initiatives will revolve more around application platforms from Oracle, Salesforce, ServiceNow and Workday. Every major provider of enterprise applications offers low-code and no-code tools to customize their applications. Many enterprise IT organizations are employing these tools more widely to accelerate digital business initiatives as an alternative to building entire applications from the ground up.

    The challenge these organizations will soon encounter is that as the backlog of applications that need to be deployed starts to build, they will have to modernize their approaches to deploying applications to keep pace.

    As a dominant provider of enterprise applications, SAP is in a position to drive digital business transformation in a way that extends the reach and scope of its enterprise resource planning (ERP) portfolio. The issue is finding a way to accomplish that goal when organizations thanks to the COVID-19 pandemic have a pressing need to transform much sooner than later.

  • Eclipse Foundation Formally Releases Jakarta EE 9 Spec

    Eclipse Foundation Formally Releases Jakarta EE 9 Spec

    The post-Java Enterprise Edition (EE) era has formally begun with the release of a long-awaited Jakarta EE 9 Platform and Web Profile specification from the Eclipse Foundation.

    In addition, the Eclipse Foundation has announced that version 6.0.0 of the open source Glassfish application server has now been certified to be compliant with Jakarta EE 9.

    Functionally equivalent to the existing Java EE 8 specification, the release of a Jakarta EE 9 Platform and Web Profile specification is intended to enable IT vendors that have built offerings based on Java to shift their naming conventions to Jakarta EE 9.

    Mike Milinkovich, executive director of the Eclipse Foundation, said now that the Jakarta EE 9 specification is in place IT organizations should expect to see the members of the Eclipse Foundation that contribute to the project begin working more aggressively on a Jakarta EE 10 specification that adds more features.

    Under the auspices of the Eclipse Foundation, Milinkovich added there will be a lot more focus on developing a truly cloud-native implementation of Java EE as work on the next generation of Jakarta EE platform advances.

    The rate at which new capabilities were being added to Java under the stewardship of Oracle had become an issue given the rate at which other programming languages are being advanced. Oracle agreed to relinquish control of the Java specification to the Eclipse Foundation, which in theory should lead to a faster rate of innovation as more contributors participate in an open source project.

    However, Oracle insisted on retaining the rights to the Java trademark because it has support contracts in place for existing instances of Java that provide a significant stream of revenue. Providers of rival platforms based on Java are hoping enterprise IT organizations will shift quickly to Jakarta as part of a way to reduce their support costs at a time when IT teams are under intense pressure to reduce the total cost of IT.

    Despite the rise of a wide range of programming languages in recent years, Java is still widely employed with most enterprise IT organizations, many of whom have been using Java since it was first made available by Sun Microsystems. Reliance on Java is not likely to significantly decline anytime soon; however, most IT organizations are now making greater use of additional programming languages alongside Java. In fact, many of the applications that DevOps teams are building and deploying are made up of modules that were built using different programming languages.

    It may still be a while before a Jakarta EE platform is pervasively employed in IT environments. However, it’s clear a new era that should result in advances that make it easier to deploy applications that are compatible with Java faster has arrived. How those capabilities will manifest themselves may still be unclear, but the fact that they are being worked on should be a comfort to IT organizations that have already invested millions of dollars in training developers how to build Java applications optimally.

  • CloudBees Makes Software Delivery Management Apps Available

    CloudBees Makes Software Delivery Management Apps Available

    CloudBees, during an online event today, officially launched the first two modules of what will become a portfolio of software delivery management (SDM) tools delivered via the cloud.

    The first two modules have been previewed for the last year, now are generally available. The first is the CloudBees Engineering Efficiency module, which provides a system of record to normalize data in a way that makes it possible to surface metrics, analytics and actionable insights.

    Shawn Ahmed, senior vice president and general manager for software delivery automation for CloudBees, said the analytics application initially will pull data from CloudBees DevOps platforms and complementary third-party tools such as GitHub and Jira and eventually will expand to include data pulled from other continuous integration/continuous delivery (CI/CD) platforms. CloudBees Engineering Efficiency connects to more than 70 different DevOps tools. CloudBees is also making available an application programming interface (API) through which third parties can extend the module.

    The goal is to enable DevOps teams to make decisions that are informed by data rather than just gut feel, said Ahmed, noting that data can then be employed to coach DevOps teams in a way that allows them to become more efficient.

    The second module is CloudBees Feature Management, which gives DevOps teams control over how individual features are released. Organizations can manage features holistically by grouping and controlling sets of feature flags that determine what capabilities are exposed within an application. That capability makes it possible for organizations to de-couple the release of a specific feature from the rest of the delivery of an application.

    At a time when organizations are accelerating the rate at which applications are being developed and deployed to drive their digital business transformation initiatives, the ability to control how features are rolled out has become a critical element of managing the overall end user experience.

    SDM tools are part of what has become commonly known as value stream management applications. The debate that is currently occurring is to what degree these applications should be provided by the vendor that makes the CI/CD platform versus an independent software vendor (ISV) that aggregates data from multiple platforms. CloudBees is betting that as DevOps processes mature within organizations, more of them will prefer to deal with a single vendor capable of providing both the underlying DevOps platform and the tools required analyze and manage DevOps processes.

    Longer-term, Ahmed said the infusion of predictive analytics capabilities enabled by advances in machine learning algorithms means it won’t be long before organizations will be able to know if a build will fail even before it runs.

    It will be up to each organization to determine how they will apply analytics tools for DevOps processes. Ideally, the DevOps culture in place stresses collaboration and training. However, there may be some organizations that will look to use these applications to increase productivity by weeding out members of the DevOps team who lack the appropriate level of expertise. The applications being provide by CloudBees, however, are designed to identify issues in the aggregate rather than enable organizations to identify the faults of a specific member of the DevOps team, noted Ahmed.

    Like it or not, analytics applications soon will be applied more broadly to DevOps processes. The challenge and the opportunity now is determining the next best course of action based on the insights they surface.

  • GitHub Updates Server Platform for On-Prem IT Environs

    GitHub this week rolled out a series of offerings including updates to its server platform that includes a major update to the on-premises edition of the Git-based repository for source code.

    Scheduled to be available next week, GitHub CEO Nat Friedman noted via a pre-recorded video that opened the online GitHub Universe event that version 3.0 of GitHub Enterprise Server was the first update to the platform made in years. It brings with it support for capabilities such as GitHub Actions and Packages, as well as support for code scanning and, in beta, a secrets scanning capability that GitHub already makes available via its cloud service.

    GitHub Enterprise 3.0 server platform now also supports GitHub Mobile to enable developers to work remotely.
    The Microsoft subsidiary is also moving to extend the capabilities of its cloud service with the addition of an auto-merge capability, available in beta, that allows authors of pull requests to opt in to having a pull request merged automatically once its required reviews or status checks have passed. Previously, DevOps teams were required to wait until pull requests were completed before moving on to the next task.

    GitHub also announced that its previously previewed Discussion collaboration tool is now available as a public beta on all public repositories. The company plans to extend the capability to GitHub Mobile soon.

    Other capabilities being added in beta include environments to more easily isolate workflows among team members, a dependency review tool, support for required reviewers, access to deployments and deployment logs and a workflow visualizer for DevOps pipelines.

    GitHub is also providing DevOps teams with a dark mode option available in beta.

    Finally, GitHub has extended its GitHub Sponsors program to enable organizations to contribute funds directly to developers working on specific open source projects. Many of those contributors are finding they can make as much money via contributions as they previously had for a single employer, noted Freidman.

    Friedman said GitHub is, as ever, committed to continuing to improve the developer experience. Naturally, those capabilities will continue to manifest themselves first on the GitHub cloud platform.

    The degree to which that sits well with IT organizations that prefer to develop applications using repositories they deploy and control remains to be seen. While more application development is occurring in the cloud than ever, there are still plenty of organizations that are wary of making intellectual property available on any type of cloud platform. Many organizations are also pursuing hybrid approaches that employ a mix of Git-based repositories based on the sensitivity of the application development project.

    Regardless of the Git repository employed, automated workflows that are enabled by GitOps processes are becoming more widely employed. Less clear is to what degree those GitOps workflows will need to be extended across multiple Git repositories at a time when enterprise IT environments are becoming more hybrid. In those environments, parity between on-premises and cloud-based Git repositories will rapidly become an essential requirement.

  • DataStax Delivers on Open APIs Commitment

    DataStax Delivers on Open APIs Commitment

    DataStax announced today the general availability of the open source Stargate application programming interface (API) framework for building applications on the Cassandra database.

    Ed Anuff, chief product officer at DataStax, said Stargate will make it easier for developers to use de facto standard REST API, GraphQL API, schemaless Document API or JSON to build applications that run on Cassandra.

    Previously, developers had to employ a unique set of APIs to build applications for an open source database based on wide-column store architecture. That often resulted in IT teams employing Cassandra only when their applications ran into scaling issues on other platforms, said Anuff.

    Stargate will now make it possible for developers to use APIs they already know to build applications that are deployed initially on Cassandra. That, Anuff said, should reduce the headaches that are encountered whenever an organization is required to move an application from one database to another.

    Stargate is available for download via the Astra cloud database service, a managed instance of Cassandra provided by DataStax. Initially previewed last summer, Stargate also makes it possible to store JSON objects in Astra without any upfront modeling required to more easily prototype applications without having to pre-define schema and queries.

    DataStax is clearly trying to make it easier for developers to both build applications for Cassandra and move them if required. Many developers tend to embrace document databases early on simply because they tend to be more accessible and don’t typically require a database administrator to deploy and manage. As those applications start to scale, however, it’s not uncommon for developers to have to rehost them on another platform.

    In general, Anuff said database management is finally starting to be incorporated into a larger set of DevOps processes within many IT organizations. At the same time, traditional DBAs are migrating into DataOps or CloudOps engineering roles that have been created to manage data across a wide range of data stores. The days when DBAs typically identified themselves with a single type of database platform are now largely over, he said, noting IT organizations are instead moving to models where data is made available as a service regardless of where it is stored via standard APIs.

    DataStax is making a case for using Cassandra as the foundation for data services because of the platform’s ability to scale those services over time.

    It’s hard to say how the database platform wars will ultimately play out. Many IT teams routinely make use of a wide range of databases and data stores. Nevertheless, there is now a lot more pressure to reduce the total cost of IT, which may lead more organizations to rationalize the number and types of database platform they support.

    Regardless of the database platform selected, the way data is accessed in the enterprise has utterly changed. The challenge now is conforming the processes employed to build and deploy applications to the way data is now managed.

  • CD Foundation Embraces Ortelius to Manage Microservices Deployments

    CD Foundation Embraces Ortelius to Manage Microservices Deployments

    The Continuous Delivery (CD) Foundation has added the open source Ortelius platform for managing the deployment of microservices as an incubation level project.

    Originally developed by DeployHub, Ortelius was created to provide a means to automate configuration at the application level. It also provides a central catalog of services that makes it easier to consume and deploy services across clusters that also tracks application versions and dependencies as updates to services are made.

    DeployHub CEO Tracy Ragan said Ortelius is now being donated to the CD Foundation, an arm of the Linux Foundation, which is working to create de facto continuous delivery standards. As such, Ortelius will benefit from contributions from other members of the consortium that includes Google, CloudBees, CircleCI, JFrog, IBM, GitLab, Netflix and DeployHub.

    The core CF Foundation projects are the open source Jenkins continuous integration/continuous delivery (CI/CD) platform; Jenkins X, an open source CI/CD solution on Kubernetes; Spinnaker, an open source CD platform; and the Tekton specification for building CI/CD components.

    Ortelius already integrates with CD orchestration tools and deployment tools such as Helm, Ansible and Spinnaker. The opportunity now is to address the entire application development life cycle of cloud-native applications using a GitOps methodology, said Ragan.

    While in theory the rise of Kubernetes should make it easier to automate CD processes across multiple platforms, Ragan noted that in practice there are still substantial differences between instances of Kubernetes that will require tools to automate the rollout of microservices across multiple clusters. Ortelius allows IT teams to logically manage groups for microservices as a single entity in much the same way IT teams manage monolithic applications as a single entity, she said.

    Ragan also noted that not all microservices are of equal value, so different approaches to managing them are required based on the number of dependencies they have and the value of the microservices to the business. As it becomes apparent IT teams will soon be managing perhaps thousands of microservices, the need for a standard approach that integrates with multiple CD platforms becomes more acute. In fact, she said, IT teams are approaching a new era when chaos engineering principles will need to be applied to the management of microservices.

    Longer-term, Ragan said Ortelius will also make it feasible to employ machine learning algorithms to provide predictive analytics that can be used to optimize the microservices environment. That capability eventually will provide a critical capability for managing microservices at scale. It may also serve to further the adoption of best CD practices that thus far have proven elusive to achieve in IT environments where each platform has unique attributes that make automating application delivery challenging regardless of what type of application is involved.

    In the meantime, IT organizations are being invited to contribute to the Ortelius project, now that it’s part of the CD Foundation. The more contributions that are made, the sooner the Ortelius platform graduates, which can’t come soon enough for many organizations that have already invested in microservices.

  • Apollo GraphQL Offers Free API Management Service

    Apollo GraphQL Offers Free API Management Service

    Apollo GraphQL has announced the general availability of a free Development Graphs cloud service to simplify management of GraphQL application programming interfaces (APIs) at scale.

    GraphQL APIs have been gaining traction as an alternative to REST APIs because they provide developers with more control over who can access data via an API and are easier to build and maintain.

    Apollo GraphQL CTO Matt DeBergalis said that approach makes it possible to build APIs using the Agile development methodology versus the waterfall processes that typically are employed today to construct REST APIs.

    Originally developed by Facebook, GraphQL APIs are being extended by Apollo GraphQL via a set of Studio tools based on a graph that makes it easier to discover those APIs and search GraphQL schemas. IT teams can also use the tools to launch queries against those APIs using an integrated development environment (IDE) dubbed Explorer. Developers are not required to have a deep knowledge of GraphQL syntax or the shape of a schema to launch a query. They can also copy links to share their queries with other users to copy a version of a query that can be run in the terminal as a CURL command.

    DevOps teams can also search for types and fields in a schema using tools that guide them through the process of querying any field in their schema. They also can find and add fields to a query without needing to know in advance where those schemas are actually running.

    The tools also make it possible to view samples of results to better gauge what data will be returned by a query, along with latency rates for each field in a query to better understand the overall cost of a query.

    DevOps teams can also view response data from their queries as JSON or as tables and create mock responses to queries to test operations, Finally, each request and view of every query can be viewed alongside the data returned.

    Connections to a private sandbox in the cloud for each local GraphQL server or any development environment are enabled using the Development Graphs tool.

    DeBergalis said he doesn’t expect most DevOps teams will rip and replace the REST APIs that are already strewn across most extended enterprise. Instead, most new applications will make use of GraphQL APIs that over time will become the de facto standard for building APIs. However, developers are clearly voting with their feet to abandon REST APIs in favor of a more agile approach, he said.

    Apollo GraphQL is looking to become the software development lifecycle (SDLC) platform for managing GraphQL APIs at scale, DeBergalis added.

    The challenge organizations face now is finding a way to integrate the management of those GraphQL APIs within the context of a larger set of DevOps workflows. Of course, that may wind up being more challenging than initially anticipated when they consider REST and GraphQL APIs could be employed alongside one another for years to come.