Tom Petrocelli is a Research Fellow with Amalgam Insights. His area of interests are in Collaboration and new ways of work, developer tools, IT project efficiency, governance, and methodologies, and DevOps. Most recently, Tom worked for a large, global, banking corporation. Previously, he was the research director for Enterprise Social, Mobile and Cloud Applications at Neuralytix.
Before joining Neuralytix, Mr. Petrocelli was the senior analyst, Social Enterprise at Enterprise Strategy Group (ESG) where he covered social collaboration, social media, and the impact of social, mobile and cloud on the software industry. Before ESG, he was Senior Vice President for Enterprise Software at IP.COM where he led the software business unit.
Companies struggle with all types of compliance issues. Failure to comply with government regulations, such as Dodd-Frank, EPA or HIPAA, is a significant business risk for many companies. Internally mandated compliance also represents problems as well. Security and cost control policies are just as vital as other forms of regulation since they protect the company from reputational, financial, the operational risks. Continue reading “Infrastructure as Code Provides Advantages for Proactive Compliance”
Tom Petrocelli, Amalgam Insights Research FellowDevelopment organization continue to feel increasing pressure to produce better code more quickly. To help accomplish that faster-better philosophy, a number of methodologies have emerged that that help organizations quickly merge individual code, test it, and deploy to production. While DevOps is actually a management methodology, it is predicated on an integrated pipeline that drives code from development to production deployment smoothly. In order to achieve these goals, companies have adopted continuous integration and continuous deployment (CI/CD) tool sets. These tools, from companies such as Atlassian and GitLab, help developers to merge individual code into the deployable code bases that make up an application and then push them out to test and production environments.
Cloud vendors have lately been releasing their own CI/CD tools to their customers. In some cases, these are extensions of existing tools, such as Microsoft Visual Team Studio on Azure. Google’s recently announced Cloud Build as well as AWS CodeDeploy and CodePipeline are CI/CD tools developed specifically for their cloud environments. Cloud CI/CD tools are rarely all-encompassing and often rely on other open source or commercial products, such as Jenkins or Git, to achieve a full CI/CD pipeline.
These products represent more than just new entries into an increasingly crowded CI/CD market. They are clearly part of a longer-term strategy by cloud service providers to become so integrated into the DevOps pipeline that moving to a new vendor or adopting a multi-cloud strategy would be much more difficult. Many developers start with a single cloud service provider in order to explore cloud computing and deploy their initial applications. Adopting the cloud vendor’s CI/CD tools embeds the cloud vendor deeply in the development process. The cloud service provider is no longer sitting at the end of the development pipeline; They are integrated and vital to the development process itself. Even in the case where the cloud service provider CI/CD tools support hybrid cloud deployments, they are always designed for the cloud vendors own offerings. Google Cloud Build and Microsoft Visual Studio certainly follow this model.
There is danger for commercial vendors of CI/CD products outside these cloud vendors. They are now competing with native products, integrated into the sales and technical environment of the cloud vendor. Purchasing products from a cloud vendor is as easy as buying anything else from the cloud portal and they are immediately aware of the services the cloud vendor offers. No fuss, no muss.
This isn’t a problem for companies committed to a particular cloud service provider. Using native tools designed for the primary environment offers better integration, less work, and ease of use that is hard to achieve with external tools. The cost of these tools is often utility-based and, hence, elastic based on the amount of work product flowing through the pipeline. The trend toward native cloud CI/CD tools also helps explain Microsoft’s purchase of GitHub. GitHub, while cloud agnostic, will be much for powerful when completely integrated into Azure – for Microsoft customers anyway.
Building tools that strongly embed a particular cloud vendor into the DevOps pipeline is clearly strategic even if it promotes monoculture. There will be advantages for customers as well as cloud vendors. It remains to be seen if the advantages to customers overcome the inevitable vendor lock-in that the CI/CD tools are meant to create.
I am constantly asked the question “What does one have to do to implement DevOps”, or some variant. Most people who ask this question say how they have spent time searching for an answer. The pat answers they encounter typically is either technology-based (“buy these products and achieve DevOps magic”) or a management one such…
Please register or log into your Free Amalgam Insights Community account to read more. Log InRegister
Two weeks ago (May 21, 2018), at Informatica World 2018, Informatica announced a new phase in its partnership with Microsoft. Slated for release in the second half of 2018, the two companies announced that Informatica’s Integration Platform as a Service, or IPaaS, would be available on Microsoft Azure as a native service. This is a different arrangement than Informatica has with other cloud vendors such as Google or Amazon AWS. In those cases, Informatica is more of an engineering partner, developing connectors for their on-premises and cloud offerings. Instead, Informatica IPaaS will be available from the Azure Portal and integrated with other Azure services, especially Azure SQL Server, Microsoft’s cloud database and Azure SQL Data Warehouse.
Please register or log into your Free Amalgam Insights Community account to read more. Log InRegister
It’s not news that there is a lot of buzz around containers. As companies begin to widely deploy microservices architectures, containers are the obvious choice with which to implement them. As companies deploy container clusters into production, however, an issue has to be dealt with immediately: container architectures have a lot of moving parts. The…
Please register or log into your Free Amalgam Insights Community account to read more. Log InRegister
Tom Petrocelli, Amalgam Insights Research FellowOver the past two weeks, I’ve been to two conferences that are run by an open source community. The first was the CloudFoundry Summit in Boston followed by KubeCon+CloudNativeCon Europe 2018 in Copenhagen. At both, I found passionate and vibrant communities of sysops, developers, and companies. For those unfamiliar with CloudFoundry and Kubernetes, they are open source technologies that abstract software infrastructure to make it easier for developers and sysops to deliver applications more quickly.
Both serve similar communities and have a generally similar goal. There is some overlap – CloudFoundry has its own container and container orchestration capability – but the two technologies are mostly complementary. It is possible, for example, to deploy CloudFoundry as a Kubernetes cluster and use CloudFoundry to deploy Kubernetes. I met with IT professionals that are doing one or both of these. The same is true for OpenStack and CloudFoundry (and Kubernetes for that matter). OpenStack is used to abstract the hardware infrastructure, in effect creating a cloud within a data center. It is a tool used by sysops to provision hardware as easily scalable resources, creating a private cloud. So, like CloudFoundry does for software, OpenStack helps to manage resources more easily so that a sysop doesn’t have to do everything by hand. CloudFoundry and OpenStack are clearly complementary. Sysops use OpenStack to create resources in the form of a private cloud; developers then use CloudFoundry to pull together private and public cloud resources into a platform they deploy applications to. Kubernetes can be found in any of those places.
Fake News, Fake Controversies
Why then, is there this constant tension between the communities and adopters of these technologies? It’s as if carpenters had hammer people and saw people who argued over which was better. According to my carpenter friends, they don’t. The foundations and vendors avoid this type of talk, but these kinds of discussions are happening at the practitioner and contributor level all the time. During KubeCon+CloudnativeCon Europe 2018, I saw a number of tweets that, in essence, said: “Why is Cloud Foundry Executive Director Abby Kearns speaking at KubeCon?” They questioned what one had to do with the other. Why not question what peanut butter and jelly have to do with each other?
Since each of these open source projects (and the products based on them) have a different place in a modern hybrid cloud infrastructure, how is it that very smart people are being so short-sighted? Clearly, there is a problem in these communities that limit their point of view. One theory lies in what it takes to proselytize these projects within an organization and wider community. To put it succinctly, to get corporate buy-in and widespread adoption, community members have to become strongly focused on their specific project. So focused, that some put on blinders and can no longer see the big picture. In fact, in order to sell the world on something that seems radical at first, you trade real vision for tunnel vision.
People become invested in what they do and that’s good for these type of community developed technologies. They require a commitment to a project that can’t be driven by any one company and may not pan out. It turns toxic when the separate communities become so ensconced in their own little corner of the tech world that they can’t see the big picture. The very nature of these projects defies an overriding authority that demands the everyone get along, so they don’t always.
It’s time to get some perspective, to see the big picture. We have an embarrassment of technology abstraction riches. It’s time to look up from individual projects and see the wider world. Your organizations will love you for it.
Standing in the main expo hall of KubeCon+CloudNativeCon Europe 2018 in Copenhagen, the richness of the Kubernetes ecosystem is readily apparent. There are booths everywhere, addressing all the infrastructure needs for an enterprise cluster. There are meetings everywhere for the open source projects that make up the Kubernetes and Cloud Native base of technology. The…
Please register or log into your Free Amalgam Insights Community account to read more. Log InRegister
(Note: This blog is an excerpt from Tom Petrocelli’s current report: Infrastructure as Code: Managing Hybrid Infrastructure at Scale) Key Stakeholders: CIO, Sysops, System Admins, Network Admins, Storage Admins, IT Operations Managers Why It Matters: New software architectures continue to add complexity to it infrastructure management. At the same time, organizations expect IT to deploy…
Please register or log into your Free Amalgam Insights Community account to read more. Log InRegister
Tom Petrocelli, Amalgam Insights Contributing Analyst
Oracle Labs has recently (April 17, 2018) announced the 1.0 release of GraalVM. GraalVM is an open source language virtual machine(VM), much like the Java VM or Node.js virtual machine. What makes GraalVM interesting, is that it can execute code written in a variety of languages including Java (and Java VM based languages such as Scala, Groovy, or Kotlin), R, JavaScript, along with Ruby, R, and Python. This is a departure from mainstream VM designs. It is much more common to have separate and specific VMs for languages such as PHP or Python. In some cases, a language will byte compile to a different virtual machine, for instance Clojure compiling to the run on the Java VM. Those languages are purpose built to run on a specific VM. GraalVM, on the other hand, runs code written in languages originally built for their own VM.
This approach offers advantages over the traditional approach of one language, one VM. For example, any program that is compiled for GraalVM can share libraries with other programs that is likewise compiled. Developers can write in different languages but still maintain interoperability and code reuse across them all. This also allows developers to continue to use code written in “older languages” while migrating to a new one. Similarly, it allows the continued used of majority language, such as Java, while leveraging languages that are built for specific purposes, such as R. Another advantage of GraalVM is ubiquity. One VM for multiple needs means fewer VMs to provision and update across IT servers and containers. That can be a serious time saver and makes maintaining large and complex systems a bit easier.
Please register or log into your Free Amalgam Insights Community account to read more. Log InRegister
Tom Petrocelli, Amalgam Insights Contributing Analyst
Blockchain looks to be one of those up and coming technologies that is constantly being talked about. Many of the largest IT companies – IBM, Microsoft, and Oracle to name few – plus a not-for-profit or two are heavily promoting blockchain. Clearly, there is intense interest, much of it fueled by exotic-sounding cryptocurrencies such as Bitcoin and Ethereum. The big question I get asked – and analysts are supposed to be able to answer the big questions – is “What can I use blockchain for?” Continue reading “Blockchain! What is it Good For?”
