posted 3년 전 in Dev Platform category by Esen Sagynov
"What does Spring have to do with Cloud?" - you have probably asked yourself when you first saw this article. I will explain this.
In 2009, VMware acquired SpringSource, "the innovator and driving force behind some of the most popular and fastest growing open source developer communities, application frameworks, runtimes, and management tools", for approximately $362 million in cash and equity plus the assumption of approximately $58 million of unvested stock and options.
There were quite hot discussions around why VMware would acquired Spring. It seems that it's high time to look into the relationship between Spring and Cloud, as Cloud computing is on the rise.
Spring and Cloud
In the same news release SpringSource, the developer of the Spring framework, and VMware, its parent company, claim that Spring is a technology suitable for the Cloud environment. Currently, Cloud platforms related to Spring include vFabric, Cloud Foundry, VMForce and Google App Engine.
A solution for private Cloud offered by VMware, which provides a technology stack consisting of, among other things, the virtualization solution of VMware and the middleware, framework and development tools of SpringSource.
- Cloud Foundry
A Cloud service operated by SpringSource, which uses Amazon’s AWS and provides middleware including Tomcat.
A Cloud service offered jointly by VMware and Salesforce.com, which uses Force.com database and encompasses VMware’s solutions such as Spring, Tomcat and vSphere.
- Google App Engine
As the result of a partnership between Google and VMware, SpringSource’s development tools now support Google App Engine. A plug-in is provided, which allows the development of an application that uses Google App Engine at Spring Roo.
At the SpringOne conference held in October 2010, the promotion of Cloud was notable. Spring was combined with diverse Cloud solutions, including vFabric, CloudFoundry, VMForce and even Google App Engine. Two of the three platinum sponsors for SpringOne 2010 were Google and Salesforce.com.
"Spring is just an application framework. What does it have to do with Cloud?" - you would ask. "Aren't the core technologies of Cloud the virtualization and the distributed storage? Why would not Struts or Google Guice run in a Cloud environment instead of Spring, if JVM is correctly in place? These days, any technology that involves multiple servers is called Cloud. Isn’t Spring just one of these?" All we know at this moment is that these questions are not groundless.
Instead of dismissing such moves by major vendors as part of their promotion strategies, it will be useful in understanding the trend in technologies if we look into why VMware, Google and Salesforce.com are trying to accommodate Spring.
Last 10 years and profitable models
As it is widely known, Spring started as an alternative technology to the Java EE standard in the early EJB era.
Rob Johnson, the founding father of Spring, addressed the challenges in the early EJB era and developed his own framework, whose code was later disclosed in his book “Expert one to one J2EE development.” The code received such a positive response from developers that it became an open-source project. The Spring framework became popular enough for nine out of the ten top global banks to adopt it, and as a result, core developers founded a business entity to receive venture capital.
SpringSource must have thought a lot about its profit model since its foundation. How can a mere application framework bring in money? The company once considered devising something called an enterprise service, in which minor patch versions would be offered to license purchasers.
SpringSource started to use M&A to secure products other than the framework. The first firm it had acquired was Covalent, where the core developers of Tomcat and Apache HTTPD are employed. The decision to acquire Covalent must have come out of a recognition that despite a pretext to integrate framework and middleware, a framework alone would not be enough for profit generation.
To everybody’s surprise, SpringSource itself was acquired by VMware for about 420 million dollars in 2009. The price was startling, as it was worth 530 thousand servers costing one thousand dollars each, but more startling was the buyer, VMware. It was not a middleware vendor like Oracle or IBM, which Java developers are familiar with, but a virtualization solution vendor, which on the surface seems distant from Java.
Rod Johnson had looked for a business model with scalability. A business model based on consulting and training only would end up being a profit structure based on labor cost. So a model to sell products and services was required. Yet the big difference between the commercial version and the open source version would lead to criticism that the company was treating the open-source community poorly. SpringSource was offering Tomcat reinforced with tc Server, and if bugs are found in Tomcat that did not exist in tc Server, it would face huge criticism. Such restrictions in product selling probably made Rod Johnson decide to go for Cloud service, which is a scalable business model. That is why VMware was the buyer.
Apart from the business background, it is necessary to look into whether combining Spring and Cloud makes technological sense and what efforts had to be made for the combination.
Expansion of Spring portfolio and Cloud
Spring has picked up speed in evolution since its acquisition by VMware. Looking at projects, such as Spring-Android and Spring-Hadoop these days, it is hard to think of an area in which Spring has not had a hand.
Technologies associated with Cloud can be classified as follows:
First, there are technologies whose middleware for processing large volume was taken over from Spring directly. RabbitMQ, an AMQP (Advanced Message Queuing Protocol) based MQ solution, and GemFire, a datagrid technology, are two examples. Asynchronous processing and data cache will be more widely used in a Cloud environment, where large volume processing takes place frequently.
Second, there are technologies which provide API wrapping for distributed storage.
There are many projects for storage ongoing, under a project called Spring-data. Redis, Riak, CouchDB , MongoDB, Neo4j and more are already supported. There is no problem, of course, in using such storage without support from Spring. The objective of such projects is to ensure that the storage API facilitates convenient and consistent use of the API with Spring’s setting and programming method, just as Spring-jdbc is used instead of the direct use of JDBC. Storage APIs will not be as inconvenient as JDBC, but there will be some room for improvement, including a reduction in repeated Try-catch caused by Template-callback pattern.
Cache abstraction in Spring 3.1 facilitates the convenient use of distributed cache solutions. It allows designation of the objects to cache and the keys with Annotation, which is similar to the transaction processing method. Implementations for EhCache are provided by default, and diverse caches can be used to this specification once tuned to the SPI (Service Provider Interface).
Third, there are monitoring technologies. In a Cloud environment, many server and middleware instances are actually used, even if the user does not pay much attention to the physical server. The use of resources may need to be checked, since you only pay for what you use. A quick understanding of the use pattern is also useful in determining the cost and benefit. That is why monitoring is much more highly emphasized than in traditional systems. SpringSource’s acquisition of Hyperic, a monitoring tool, and development of tools like Spring-insight, can be understood in such context. In Spring-insight, Spring-specific information including Controller information for Spring MVC is provided, which is probably to highlight the benefits realized with Spring.
MQ data storages, cache and monitoring technologies can be installed and used in the existing environment, but can also be included in the technology stack offered as part of a Cloud service. Default solutions are an important part of the competitive edge, even in Cloud service. Amazon’s Cloud includes SQA (Simple Queue Service) as MQ and SimpleDB as storage, while Google App engine has Memcache as cache and BigTable-based DataStore as storage. vFabric, a Cloud solution offered by VMware, uses Gemfire for session clustering for the tc Server, and carries out monitoring with Hyperic.
A large portion of the recent expansion of Spring is related to technology investment in line with the cloud era.
Spring and Cloud portability
At SpringOne 2010, there was a demonstration in which an application running in VMware’s Cloud was run in Google's App Engine in exactly the same way. This is not surprising in a way, considering the portability of JVM. What is the implication of this?
One who intends to adopt Cloud should take into account what will happen over time. For example, an application may need to be transferred from a legacy server to Cloud, from Cloud to another Cloud, or from Cloud to a non-cloud. The greater the part of the application is dependent on a specific running environment, the more burdened the owner of the application will feel. Tying an application to a specific Cloud may seem to be an advantage for Cloud vendors, but it will hinder expansion of the user base because it can deter prospective users from adopting Cloud in its early stages. Existing applications will not be uploaded if it is expensive to move to Cloud. The user will be at a disadvantage in negotiation over pricing if it is difficult for him to exit even after moving-out. Consequently, when trying to expand the market, it will be to the advantage of Cloud vendors to emphasize that Cloud users can upload existing applications with minor modifications, and move out easily.
Meanwhile, will the Cloud environment accommodate existing applications as they are? This is not an easy task even for WAS, which Web applications are loaded onto. In Cloud services, only a small number of WASes are available. Google App Engine uses a variant of Jetty and Cloud Foundry, VMForce and vFabric, all of which are operated by VMware, and needless to say, use tc Server, a commercial version of Tomcat. Moreover, JVM and WAS used in Cloud have limitations in their functions.
In Google App Engine, no file can be written directly, and no thread or socket can be created. In Servlet spec, the method used to call ServletContext.getNamedDispatcher and find out the name of the default Servlet does not work properly, either. All of this means that elements with the risk of security breach or abuse are not supported. When a legacy system is transferred to a Cloud environment, it is highly likely that the two WASes in the legacy system and in the Cloud are different. This is even more likely if the existing WAS is a Java EE server. Moreover, the function to call from WAS itself or the application will be restricted as well.
Here, Spring can be a big help for Cloud vendors. It can compensate for the weakness of a Cloud service, which offers WAS that supports WAS designated for the Cloud user, especially one that supports Servlet spec only. For example, life cycle management, dependency injection and declarative transaction for objects can be written with Tomcat only when there is no server that supports the JavaEE spec. Even when a JavaEE server is available, the data source and transaction service, among others, offered by the server, can be used by way of Spring. Indirect use of Java EE spec via Spring will require only minor modifications to applications at the time of switching to Tomcat or Jetty as a new WAS.
For example, you just need to change data source lookup with JNDI to DBCP, and instruct the Bean declaration to use DataSourceTransactionManager instead of JtaTransationManager. For this reason, applications using Spring have higher inter-WAS portability and a wider choice of WAS. It can be said that Spring acts as a buffer zone for WAS.
At this point, one can argue that though it is true that Spring reduces dependency on middleware such as WAS, it increases dependency on the framework itself, which in turn will reduce portability. Given such two options only, I would choose dependency on the framework rather than on WAS. A framework can co-exist with others on top of one single WAS, making it easy to change gradually. It also makes sense to have applications dependent on a framework instead of WAS in terms of flexibility. This is because version upgrade or library change for framework is easier than upgrading WAS. When it comes to changing jar files, for example, framework upgrade is done simply by changing a few lines of version declaration at pom.xml of Maven. WAS upgrade, in contrast, is burdensome compared to framework upgrade unless there is the automatic installation of AWS in place. In addition, Spring offers many methods that allow the writing of codes not dependent on it. A standard annotation such as @Inject is an example. The proper use of these methods can help reduce dependency on framework.
Salesforce.com, Google and VMware, the owner of SpringSource, all emphasize Cloud portability through Spring. The reason they speak with one voice while competing with each other is probably that for now, the initial market expansion is the most important priority. They also seem to share a belief that allowing transfer among services, instead of binding users to their own platforms, will be more beneficial in the long run. It can also be understood that all of them are confident in their core competencies, including infrastructure technologies.
Spring as a technology portal
Another reason why Spring and Cloud are linked is that Spring acts as a sort of portal in the Java technology ecosystem.
Internet portals receive a lot of visits from users and provide consistent UX for them by combining diverse information. CPs (Contents Providers) and portals enter into partnerships for contents sharing because the former can have an opportunity to make its contents widely known while the latter can bring in more visitors by offering them richer contents. User can access a wide variety of contents via portals’ consistent access routes and UX. For example, oil prices available on Naver.com, Korea's #1 search portal operated by NHN, are in fact provided by Opinet operated by Korea Oil Corporation, but users can easily access the information in the same way and style as other types of information.
Likewise, Spring is a technology used by many developers and offers a consistent setting method, annotation rules and API style by coordinating various technologies. Just as the user interface of a portal is what the user sees, the API at framework and library is the interface developers see. Companies with component technologies who partner with Spring will have a chance to increase their user base by making their technologies more widely known, just as CPs do. SpringSource, on the other hand, can benefit from a richer technology ecosystem related to Source.
Spring provides flexibility by abstracting diverse technologies into the same API, or organizing them into a similar style to reduce the initial learning cost for developers. For example, GemfireTransactionManager, which is adapted to Spring’s DB transaction management interface can be offered in Gemfire, a datagrid. Even for recently added projects like Spring-amqp, the class names, interface names and method names look familiar to anyone who knows Spring well.
VMware’s acquisition of SpringSource, partnership with Salesforce.com and Spring’s link storages like Neo4j and Terracotta and cache technologies work in some respect to pursue technological synergy. These events, however, could happen because Spring was already widely-known enough to attract people. The acquisition of SpringSource seems to have done a lot to raise awareness, since VMware is now far more familiar to Java developers. Now what needs to be done is to go beyond raising awareness to offering a synergy that users can feel.
Non-intrusive design and the Cloud era
Obviously, Spring was not intended for the Cloud era when it was first created. The rapidly changing environment requires the adaptation of Spring as well, and it has received plenty of love letters from Cloud vendors so far. The popularity of Spring is partly because it is well-known, and thus useful for publicizing. But mostly, it is the technology’s flexibility and portability that is deemed valuable, even in Cloud, which have attracted such plentiful investment and partnerships.
One of the fundamental reasons for Spring’s popularity is the technology’s design philosophy of ensuring that infrastructure related codes and business logic codes are not mutually intrusive. Spring’s POJO (Plain Old Java Object) approach ensures that Java codes not dependent on any conventions are used for core logic, so that codes less dependent on the running environment are created.
For example, infrastructure-related codes, such as codes for transaction processing, can use conventions like JTA (Java Transaction API) provided by WAS. Putting codes dependent on specific middleware together in a single place will require less modification when the middleware is replaced. In Spring, JTA-neutral transaction API (PlatformTransactionManager) is created and used via AOP to get codes using JTA together in one place, so that the modification of just a couple of lines can allow a switch to another method. As another example, Spring’s security can be used for logon verification in Google App Engine, probably because the part dependent on the infrastructure for user data storage is well abstracted.
Design must take into account, first of all, how to minimize modifications when there is a need for change in the system, instead of calling it "Cloud Portability." Design with clearly distinguished roles and responsibilities goes beyond time and environments. Eventually, flexibility and portability are the results of good modularization, and do not necessarily require special technologies. Spring’s AOP, Dependency Injection and so on only exist to support this. Before and after Spring, modularization is important, and the power behind Spring’s prosperity in the Cloud era can be attributed to having honored such universal design principles.
How different will application development be in the Cloud era? Infrastructure, like the storages and middleware required, will be a lot different. Adaptability to new components introduced into Cloud will determine productivity, at least in the early stage. Still, I don’t think the way of developing applications will be significantly different. A well-modularized code with clear roles and responsibilities will survive the new wave and exist even beyond the era, causing lower cost of modification and addition. This will be the case for whatever code is used, whether it is a framework code or application code written by an app developer.
How can one demonstrate that he or she has created a code with clear roles and responsibilities? Just write a test code. It will be difficult to write a test code if the code for infrastructure management and the code for business rules are mixed. Such a code will required more and more costs for modification, and eventually will not survive. Use of a specific framework does not necessarily lead to a good design. The best way to determine whether Spring is optimally utilized will be to see whether you write a code that allows the easy writing of a test code.
The increased investment by SpringSource in Cloud-related technologies was part of its plan to identify a scalable model, and has already produced some tangible results through a reinforced portfolio and partnerships. Spring can be an asset for Cloud that provides limited WAS due to its scalability, and is recognized for its role as a portal for a technology ecosystem with a wide user base. However, the fundamental reason for the prosperity and adaptation of Spring in the Cloud era is that it is a technology that allows the separate design of application core logic and infrastructure.
There will be a rush of news about Spring throughout the year, and most of it will be related to Cloud. I hope their strategies will unfold in a way that benefits all participants in the Java ecosystem.
By Jung Sang Hyuk, Manager, Productivity Innovation Team, NHN Business Platform Corp.