“Not only does Spring make developers more productive and responsive to business units with agile needs, it helps enterprises lower operating and capital costs within IT,” says Jim Nuzzo, EMC Enterprise Architect and Cloud Platform Manager.
In this article, Mr. Nuzzo continues with part two of a recent Q&A session. He shares how EMC started using the Spring Framework, how it became a standard, why Spring makes their teams more productive, and how they use it for enterprise integration. Along the way, he points out the financial impacts it makes in IT.
In part one, Mr. Nuzzo, shared how EMC uses two other Pivotal products—Pivotal GemFire and Pivotal SQLFire. He explains the challenges, solution, and results for Pivotal GemFire on EMC.com and Pivotal SQLFire for the support website. In a nutshell, GemFire was used to scale sessions and helped EMC improve the number of concurrent users per server by 10x, ultimately reducing the number of servers used and associated capital and operating expenses. With SQLFire, EMC was able to bring data together across three separate databases, and join queries improved 200x.
How did EMC start using Spring and how did it become a standard?
We started using both the Spring Framework and Pivotal components about six years ago. We originally became interested in Spring for web application development. At the time, we had a lot of homegrown web applications being built with various frameworks. What attracted us to Spring was Spring MVC—we could use it to consistently generate high quality web applications and provide uniform support with different developers. We promoted it within IT as a standard and successfully began to deliver apps across various lines of business. Over time, the use of Spring graduated into our very large web applications. Almost two years ago, we began an IT transformation initiative, and Spring became a central part of it. We had several EJB-based, heavy container types of applications. These have all gone to Spring, and we have a much faster, more agile release cycle. This makes our business units much happier. So, Spring with a lightweight runtime container is now a standard at EMC.
Could you tell more about your standardized stack and what it does for you?
Our standard stack is EMC hardware, vSphere and ESX for virtualization, Pivotal tc Server, and the Spring Framework. For example, our application integration cloud fabric has over 64 servers in production. Everything is 100% virtualized. These are Pivotal tc Servers running Spring Integration components. We also run both GemFire and SQLFire on tc Server with Spring. This standard is advantageous from several perspectives. There is uniform monitoring, uniform performance tuning, consistent build processes, consistent operations, consistent security, and more. Standards improve our productivity, reduce errors, and drive costs down.
You said EJB has migrated to Spring and lightweight containers. Why are lightweight containers like Apache Tomcat and Pivotal tc Server replacing heavyweight containers like Websphere and Weblogic?
Well, these are two very different programming frameworks and runtime containers. EJBs tend to be thought of as intrusive. For example, your code references superclasses and utilities within the container. With the volume of these types of extra classes, the container becomes rather large and cumbersome. This adds complexity and system overhead in cases where it is unnecessary. It forces you to run services that are not needed. Your code becomes dependent on the container, making a tight coupling. As well, developers have to fire up a huge server to develop or test every change.
With Spring, we use plain old Java objects—POJOs and dependency injection. The code has no ties to the framework or the container. You can even test your code without starting up the container. There is basically no vendor lock-in to the runtime.
So, as you move to the Spring Framework, you can migrate away from heavyweight EJB containers like Websphere, OC4J, and Weblogic. With a lightweight framework and runtime like Tomcat or tc Server, you use much less memory and disk for the application. For a single server, we are talking tens of megabytes versus hundreds—it’s an order of magnitude difference for memory and disk. Imagine the cost implications across thousands of servers. For EMC, moving from EJBs to Spring is now a standard migration, and Spring is our standard platform for new development efforts. It’s much more cost effective from a computational standpoint, and you don’t need as large of compute resources to run applications. In my view, Spring’s developer advantages drive the introduction of a new container; however, the new container includes many cost benefits that fit into an overall decision to migrate.
Could you give us an example of how you recently used Spring within a project at EMC?
Sure. About two years ago, we started an IT transformation, and it involved the replacement of an ERP system. This also presented an opportunity to address a fragmented and diverse set of integrations. We had four separate integration platforms at the time—this meant four different skill sets, four different sets of infrastructure, four support models, and four contracts. There were about 425 different point-to-point integrations. So, we knew a common integration platform would reduce costs, but we also wanted to be more productive in delivery. My team was responsible for this platform.
The architecture included Spring Integration, Spring Data, and Spring Batch. We finished the project this past June, and it has been a great success. Our prior 425 point-to-point integrations were reduced to 125 integrations. We also support many integration patterns like PubSub, PubSub with strict ordering, batch, web services, and more.
Importantly, we have also reduced our time to delivery or increased our productivity as a development team. This doesn’t always happen in big projects that consolidate several separate, smaller projects. Often times, a bigger application slows development down, but not for our team. In the past, it took us over 35 days to develop a single integration. Now, we can do it in 10 days. Before, we didn’t re-use any code. Now, about 50% of our integrations include re-usable code.
Financial outcomes are always important, and, in this case, we achieved a lower capital and a lower operating cost with this new integration platform. Now, we have a linearly scalable, cloud-based environment that also happens to use Pivotal GemFire, but that is another story.
Learn more about the Spring products mentioned in this article:
- Articles: 3 Steps to Migrate Spring Apps to Real-Time Data Grids and Run Spring Apps 60x Faster with Spring Data and Pivotal GemFire
- Spring Website and Blog
- Get started with Spring via Guides and Tutorials
- What is Spring Support?
- What type of Spring Consulting or Training is available?
