Three Ways to Do Web Apps in the Cloud
Three Ways to Do Web Apps in the Cloud
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Web apps were born to run in the cloud. With endless flexibility, on-demand scaling and great pricing, the cloud meets the business and technical needs of many enterprises’ web-based applications for e-commerce, collaboration, marketing, CRM and dozens of other functions. With their ‘spikey’ needs for compute resources around peak periods, web apps are often corporate data center hogs and/or hosted at colos and MSPs at high cost.
As we work with many enterprise customers, we consistently hear the desire to host web apps in the cloud to reduce data center costs, footprints and headaches. There seem to be three major use cases emerging in the cloud market, reflecting the ways in which specific web apps are architected, and the comfort levels of the customer in exposing some or all of their app stacks outside the corporate firewall:
- Build the entire web application to run in the cloud. Launch some raw servers in the cloud and create your application using simple templates so that all tiers (user-facing, business logic, and database) run in the cloud. If you are putting up a new public web site, this is a great way to get into the cloud, and is particularly useful if you do not need to access data or systems that already exist within your data center. Many new companies and start-ups already also use this approach since they don’t have any legacy infrastructure to integrate with!
- Move parts of the application to the cloud. Keep some of the app components internal and move others to the cloud. For example, put the user-facing portion of the application stack in the cloud for scaling and access by large numbers of users, and let it reach back to the data center to access your business logic and/or database tiers. Some of our customers put the user-facing and business logic in the cloud and reach back for the main database, while others put just the public access portions into the cloud. The key considerations are what kind of data the application needs to access, how much data is required, and the application’s sensitivity to latency between the tiers. If data is very sensitive, the pull is to keep it in the data center, but if the application is susceptible to database latency, the desire is to move data to the cloud to be near the computation servers. Even when all tiers are moved to the cloud, there is often a need to access data center resources (for management, user validation, or ancillary data).
- Use the cloud for peak-period scaling. This approach involves scaling portions of the web application into the cloud during peak periods, such as for a Mother’s Day sale or when the tax filing deadline approaches. Based on a peak-workload trigger, move base images of the app into the cloud and let them scale away. Add the new cloud resources to your load balancers to keep response times low during peak usage. When you need occasional access to massive compute resources, the cloud provides a great alternative to buying and maintaining expensive equipment. The cloud essentially becomes an extension of your data center for on-demand scenarios.
Which of these approaches will work best for you? Many enterprises are testing more than one approach with different web applications as they define their cloud strategies. CloudSwitch technology lets you get started now with no risk, moving applications (or selected portions) to the right cloud, and keeping cloud resources in seamless integration with your data center. Put your web apps where they belong and free yourself from endless infrastructure heavy-lifting.
Published at DZone with permission of Ellen Rubin . See the original article here.
Opinions expressed by DZone contributors are their own.