Turbonomic Blog

The event of the season is right around the corner: Apps ON Cloud Summit! 

Turbonomic is thrilled to be hosting this virtual event, bringing together some of the biggest names in tech to discuss the most prevalent challenges IT organizations face—and how to solve them. 

For any digital business, applications are what connect you to your customer. Leading organizations are leveraging public cloud and cloud native to innovate faster, grow their business, and delight their customers. But the promise of the modern technology is often unfilled as organizations grapple with the complexity and cultural shifts they bring along with them. 

The most common request I get from tech folks in the field is that they don’t have enough time to experiment and learn new technologies. As a systems architect in my career, I had to really work hard to stay on top of trends and new technologies with both research and hands-on usage., so I know your pain.

Spring WebFlux introduces reactive web development to the Spring ecosystem. This article will get you started with reactive systems and reactive programming with Spring. First you'll find out why reactive systems are important and how they're implemented in Spring framework 5, then you'll get a hands-on introduction to building reactive services using Spring WebFlux. We'll build our first reactive application using annotations. I'll also show you how to build a similar application using Spring's newer functional features.

There are many variations on the definition of DevOps. The central theme of them all is that DevOps is used to increase the flow of value from idea to prototype, and from prototype to production. It’s a set of processes and behavioural patterns which change the way that development and operations (and hopefully security) teams communicate, interact, and move code through the application lifecycle.

I outlined how communication challenges can lead to problems in IT organizations in my last post. In this follow-up, I want to examine how infrastructure and development teams can work together better.

Jenkins is one of the most popular open-source continuous integration and continuous delivery servers available today. It began as a product called Hudson, developed at Sun Microsystems in 2004-2005, before it was forked from Hudson and renamed Jenkins in 2011, as the result of a dispute between the Hudson community and Oracle. Kohsuke Kawaguchi, the creator of Hudson/Jenkins became the Chief Technical Officer for Cloudbees in 2014 and Cloudbees now commercially offers Jenkins as a cloud solution.

Continuous integration made integration a non-issue and brought us to the point where we always have a set of working and tested code that is ready to be deployed to production. Continuous Delivery and Continuous Deployment take the next step.

The DevOps world has matured dramatically in the past few years, enabling us to reduce development release cycles and iterate much more quickly, which has led to more rapid feature delivery and innovation. Over a decade ago we were introduced to a development practice called Continuous Integration, in which a server application automated the task of checking source code out from a source code repository, building it, and testing it, when developers check in code. Continuous Integration served us well and established the foundation for the next step in automating our build and deploy process: Continuous Delivery.
This three part article series presents an overview of Continuous Integration, Continuous Delivery, and Continuous Deployment, and introduces Jenkins as a build tool that enables all three.

As we head into VMworld I’m looking forward to seeing all of the latest and greatest from the vRealize suite. Over the last few VMworlds we’ve seen VMware cement vRealize as the umbrella brand for their management offerings.

As far as most people are concerned, a company has “The IT team” and no one seems to understand the different roles within the team. Since IT services are gaining importance for businesses, it is important to bridge any communication gaps. But let’s not rush in. Every company treats this differently, but let’s look at generic definitions…