Using old apps? New approaches for application modernization
A comprehensive collection of articles, videos and more, hand-picked by our editors
Integration services are going up, up, and away -- to the cloud that is. Research firm Gartner Inc. predicts at least 35% of midsized and larger organizations will use at least one integration platform as a service offering by 2016. While such services are gaining traction and providing useful building blocks for application development, enterprise architects are facing new challenges in monitoring and maintaining them.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In this Q&A, Cloud Elements LLC's founder and CEO Mark Geene discusses the future of enterprise cloud services and sheds light on the evolving technology and needs of architects as they begin to use cloud services.
What are the key challenges facing enterprise architects when it comes to evaluating and adopting cloud services?
Mark Geene: Your application is dependent upon many services. To run these applications, you need to manage the alerts that come in from every service. When is a service going to be down? What are the notifications? Are there response time issues? Then you have to track and monitor the notifications and response time, error rates, etc., for those services you can manage. You have to maintain where the API (application program interface) changes and make up dates to the code and the API potentially over time, and you have to do that for more and more services. If you are doing that for a dozen different services, that takes a tremendous amount of time away from developers building applications. Now, developers are spending more time monitoring and maintaining the services these applications are dependent upon.
What are some maintenance factors with enterprise cloud services that organizations need to be aware of?
Geene: It's important to create an abstraction layer between your application and the service. We recently worked with a company that needed to swap out its current payment service. Because the payment service was hard coded to an API for that one payment service, the company had to rewrite its application, and its developer had to spend about 60 hours rewriting code in order to support the new integration.
If you put the abstraction layer in place sending and receiving payments, it should be common between various services. Now, you can make that change and you don't get locked in -- you can move between services. By using an abstraction layer, you can have backup services if a payment service is down, for example. If a person is not writing to each of those services, but through that abstraction layer, he or she is able to go to multiple providers and have a backup service switch to meet future needs from an architecture perspective.
Integration is not just about the functional part, it's the operational portion of integration. How am I going to support this integration? [I have to make] sure the service is running and make sure I know the response time for that service is for tracking and logging, etc. Those are important planning aspects for integration.
What we see happening is that a typical application is built using about a half-dozen cloud services.
What cloud services are most commonly used by enterprise architects and software developers?
Geene: There are platform-level services and there are SaaS-type (Software as a Service) services that integrate into an application. What I see most often is a set of categories and services that consist of things like messaging and database as a service. Other middleware-type services are used heavily by developers. When you are building at the application-level, things like payment services and customer service management, applications like that are all readily available that can be integrated into your app.
How do you see cloud services evolving in the next few years?
Geene: There is a proliferation of SaaS services. You can now build a software service or cloud application rapidly because you can do it by gluing together pieces of other services to perform unique functionality and minimize the custom workflow. You have to build by connecting all of these different pieces together.
What we see happening is a that typical application is built using about a half-dozen cloud services. We see in the next two or three years that there is going to be 12 or 15 more cloud services integrated into an application. That is based on primary research we have done -- literally within two years, because of that proliferation of services, we see a doubling or even a tripling of services that will be integrated into applications by developers.
How have business needs evolved and changed demands to Infrastructure as a Service and Platform as a Service?
Geene: If you look at some of the drivers of cloud applications, they need to be social, they need to be mobile, they need to be services-based. We see those things driving the demand for these cloud services and cloud integrations over time. The cloud-based applications are easily integratable, which gives users flexibility as a business to be able to integrate new services and deliver them quickly.
What are some trends you see with enterprise cloud services?
Geene: We are seeing the adoption of PaaS (Platform as a Service). Enterprises that deploy test environments in private clouds are seeing the value of building an application on top of a platform as a service.
There is another level of abstraction. Instead of writing directly to services within AWS (Amazon Web Services) or Rackspace, people can write to the services provided by PaaS. If a PaaS is selected, like cloud OpenShift that is portable, an application can easily move to any infrastructure environment. We're seeing more PaaS usage moving out of the trial area in enterprises and starting to really move into deployment because they are getting the value of significant reductions in operations costs.
Note: This Q&A has been edited for clarity and brevity.
Maxine Giza is the associate site editor for SearchSOA.com and can be reached at firstname.lastname@example.org.