Turbonomic Blog

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.

Spring MVC is the Spring framework's traditional library for building Java web applications. It is one of the most popular web frameworks for building fully functional Java web applications and RESTful web services. In this tutorial, you'll get an overview of Spring MVC and learn how to build Java web applications using Spring Boot, Spring Initializr, and Thymeleaf.

Data is at the core of most enterprises today. Plenty has been written about the need to leverage insights and analytics to gain a competitive advantage as well as the mountains of data that can be collected, refined and analyzed in order to gain a competitive edge.

Why the need for in-memory databases?

In today’s business world “speed” and “agility” are two buzzy concepts that all companies aim to achieve. For the longest time advancements on the development side of the house outpaced that of the infrastructure, but with the evolution of public cloud providers, hyperconvergence, PaaS and a multitude of other offerings, IT now has the means to achieve the speed and agility that is required of them.

Databases help the business access information more quickly. This, in turn, allows employees to get more done in less time, which allows businesses to grow more rapidly. When businesses grow more rapidly, there are generally more jobs and higher pay and the economy does better. This all sounds wonderful, doesn’t it? So then why don’t we see databases helping companies and organizations progress their business faster?

Every now and again I find myself in a conversation with folks on either the database side of the fence or the infrastructure side about Microsoft SQL.  They share concerns around the necessary resources a database requires to perform reliably.  The exchange usually goes something like this: DBA wants more RAM to avoid performance bottlenecks, while the infrastructure guy knows that RAM isn’t free and it won’t necessarily solve the problem.

It's true. All of it. The Dark Side, the Jedi -- they're real. But what about this theory?

A recent customer meeting with a Toronto-based healthcare provider exemplified the typical concerns expressed around managing the SQL workloads in their x86 environment. The biggest headache, towering over the rest, centered on the transaction log located inside of every SQL database. Most questions concerned the sizing of each transaction log within the SQL server in order to utilize the IOPS from the LUNs.

It’s 2pm: Do you know where your workloads are? I require precision in the response to this question for a few simple reasons, the first of which is Oracle and Microsoft’s licensing auditing and legal teams are quite precise themselves. In fact, these companies have made quite the business out of compliance audits to the tune of billions of dollars. Of course this is old hat for most of us who have worked in IT for any measurable amount of time, but it presents a very interesting challenge that has plagued the consuming organizations of this software for years (especially their finance departments).