Huge momentum has built to migrate applications to cloud computing nowadays.
There are several motivation factors to adapt to cloud: cost savings IT
infrastructure and maintenance, time to market, rapid deployment &
provisioning, auto-scale, flexible capacity, and business continuity.
Moving existing applications is not simply a matter of lifting and shifting to
a cloud platform. Migration of existing
applications to cloud computing must be done in a strategic and systematic
manner. Identify individual business
problems with existing applications that cloud computing can potentially
address and provide specific business justification that the cloud is the right
strategic alternative.
Enterprise applications must be thoroughly assessed to determine which
application can benefit most from early migration to the cloud. Key
considerations including costs of migration, application redesign, application
performance and availability, security and privacy requirements, and regulatory
requirements must be taken into account. Create a pilot for one or two of
these types of applications, test thoroughly, and gather customer feedback so
that trust and confident can be built before going live.
The important point is that decisions about moving to the cloud need to start
from an application standpoint, with a thorough consideration of followings:
Stateless: The thump of rule is keep
your application from being affected by dynamic scaling: Build your application
to be as generic and stateless as possible. Avoid singleton.
Hardware dependency: Services that application
calls should not be pointing particular host names or IP addresses. Abstracting
environment-specific dependencies into a set of property files is still an inadequate.
A better approach is to use an external service registry to resolve service
endpoints like load balancer with virtual name.
Avoid
local file system: Avoid local file system as a store for temporary
information, put temporary information in a remote store such as an S3, Amazon
EFS, RDS or NoSQL database.
State-fullness: HTTPSession state is often
stored in-memory, which presents a problem if your entire application server
can be added or removed or moved at any time in the cloud. The best practice is
to push it out to a highly available store that is external to your application
server; that is, put it in a distributed caching store, such as
Memcached, or Redis.
Application Log Fie: Application services are in auto scaling added/moved/removed
often and storing log file in the local file system will crash your debugging
option or the file you are looking for may not be available for debug. Use an
open source aggregator, such as Scribe or Apache Flume, ELK or a commercial
product, such as Splunk.
Asynchronous Calls: Consider that asynchronous
protocols (Queue & RESTAPI) are still alive and well and can be
extremely effective for cloud application programming.
Portability: Avoid OS dependency and
application should be portable to any time of middleware. Use Cygwin and
Mono to port between Linux/.Net.
Closing
statement:
Management should realize that every significant transition in
technology has resulted in a significant rewrite or re-implementation of the
technologies that businesses depend on but deep analysis and systematic
approach converting to service-oriented architecture (SOA) can make your transition smooth and success.
