Turbonomic Blog

This blog is part of a series in which we share some of the results from our 2019 State of Performance in Modern Applications Survey.

Prefer to binge read the results? Download the full report here.

This blog kicks off a series of blogs in which we share some of the results from our State of Performance in Modern Applications Survey.

Want to binge read the results? Download the full report here.

Today we’re very excited to announce a new free tool for Developers, Lemur. Developers can use Lemur to understand their microservice applications in the context of the application stack.

This post was originally published here.

The community has been on a Kubernetes multi-cluster journey since 2015 and we’ve learned a lot along the way. As we approach KubeCon North America in San Diego, I’d like to reflect on how we got to where we are today, its origins and what the SIG is aiming for.

Today, it’s become almost sacrilegious to think about running microservices on anything but Kubernetes. But in 2016, when we first began our journey to microservices, Kubernetes didn’t have the level of maturity that it has now. Back then, we just wanted the benefits of breaking up our monolithic application into loosely coupled services. Like most organizations, the monolith served us as well as it could. But when Docker made containers easy, a whole new world opened up. At the time, docker-compose was the easiest way to start a group of containerized application services, but the very next consideration was orchestrating those containers. We soon found that docker-compose does not allow the easy distribution and orchestration of components across cluster nodes. There were also challenges with multi-node networking and shared storage across the nodes. And then Kubernetes came along.

How to Effectively Control Requests, the Silent Killer of Elasticity & Efficiency

Now that Kubernetes has graduated to enterprise-ready, organizations are looking to expand their platforms to support more applications and more lines of business. In order to do this at scale, they need to support these applications and lines of business in multitenant environments—even modern microservice applications have to share resources!

Microservices are all well and good, but these are just our modern day applications. And all applications, especially enterprise applications need to be secure. In my previous post I talked about how we were able to dynamically manage Java memory for each of the processes running in our re-architected microservices application. This was just one example of the realities we face when building an enterprise microservices application. We re-architected our application to scale with and automate some of the world’s largest hybrid cloud estates. With that kind of responsibility, every service of this application must be secured.

This is the first of a multi-part series sharing our journey to application elasticity.

Don’t Let the Complexity of Microservices and Cloud Native Stall the Next-Gen Platforms that Run Your Modern Applications

When it comes to containers, modernization is about architecting applications for speed, scale, and elasticity. Microservice architectures and the CI/CD pipelines that support them are enabling developer speed, but increase the complexity of ensuring application services continuously run. 

PaaS is a platform upon which developers can build and deploy applications. Within the PaaS market, two of the major players are Pivotal Cloud Foundry and Kubernetes. They’re both platform services for deploying cloud-native apps, and they both deal with containers, and the list goes on. These products offer a higher level of abstraction than we get from IaaS products meaning that, beyond networking, storage and servers, the application’s O/S, middleware and runtime are all managed by the PaaS.