 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
More organizations are evaluating the move to a cloud native environment. There are many factors driving this trend, but at a high level, three primary benefits stand out: quicker app development, greater scalability and less vendor lock-in.
First, the development cycle is faster for cloud native apps than legacy apps because of greater automation and the ability to leverage highly distributed services as well as continuous integration. Second, with cloud native apps, it’s much easier to scale to hundreds or thousands of services. Cloud native apps can better handle a heavier load and grow rapidly. Third, cloud native apps can be easily moved between cloud providers, so organizations are not locked into any proprietary hardware or technology like they are with traditional on-prem apps.
Cloud native environments provide major advantages. But transitioning from legacy apps to cloud native apps is not easy. It’s a long process that requires patience and planning. Many organizations suffer setbacks and unmet expectations when they try to rush this process. To avoid these problems and make these transitions as smooth as possible, any enterprise moving to cloud native apps must consider the following five tips.
When transitioning to a cloud native approach, it’s always best to start small. Organizations need to consider all the services and dependencies of a given app before moving it to the cloud. For example, certain components of an app could depend on an outbound email service or a database. When an enterprise is going cloud native, they need to be sure that all the components of an app can work with both legacy technology and cloud technology to avoid interruptions or breakdowns. Because of this, it’s best to begin with simpler apps that rely on fewer services and dependencies.
Low-risk apps are an ideal starting point. Low-risk apps can be broadly defined as apps that aren’t highly distributed, don’t need to be synced often and don’t use much user data. For example, any caching app would be considered a low-risk app.
Beyond simplicity, there are certain apps that are a better fit for going cloud native than others. Once an organization has started with a few low-risk apps to get their feet wet, they need to identify and prioritize apps that will provide the most value as cloud native. Generally speaking, there is one type of app that benefits the most from being built as cloud native: Stateless apps.
Stateless apps include most web-facing apps, which can be readily accessed by end users through the public internet. This type of app experiences rapid increases and decreases in usage. Because of this, they need to be scaled rapidly. As noted above, it’s much easier to scale a cloud native app than it is a legacy app, so stateless web-facing apps benefit tremendously from becoming cloud native. Moreover, these tend to be fairly easy to build as cloud native.
Just as there are optimal apps to take cloud native, there are also poor candidates. Any app-based heavily on a proprietary hardware technology, such as an enterprise database, isn’t a good fit to go cloud native. Large databases can’t really be moved anywhere: they typically cannot even be virtualized and must run on underlying vendor hardware. Another example is mainframe applications, which are still common in the financial services vertical. It’d take a massive effort to make a mainframe app cloud native and it’s simply not worth the trouble.
Organizations must understand that it’s not feasible or beneficial to take all of their apps cloud native, and that certain legacy apps should stay where they are. However, after enterprises successfully migrate to a cloud native environment, they often find that some of their remaining legacy apps no longer provide much value. Those applications are then simply retired.
Successfully executing a process as complicated as cloud native app adoption requires the involvement of many different teams. Organizations must include their developer, DevOps, NetOps and SecOps teams. Furthermore, these teams must be on the same page at every step and able to collaborate and communicate openly. Some enterprises think they only really need developer and DevOps teams to drive cloud native app adoption. As a result, they end up with unsecured, poorly performing cloud native apps, if they even get that far.
Service meshes are relatively new tools used for debugging, observing, encrypting and setting security policies for cloud native apps. It’s critical that organizations become proficient with the technology when transitioning to a cloud native approach, especially their SecOps teams. Cloud native apps are much more complex are harder to secure than legacy apps, introducing new attack surfaces and using far more APIs, including deeply embedded, hidden APIs. Existing security tools were not built for these apps. Enterprises should consider a good service mesh technology in order to properly monitor, automate API discovery, enforce policies and ultimately protect cloud native apps.
If an organization sells a SaaS product, there are a few extra boxes they must check to ensure that they can confidently call their SaaS apps cloud native. For one, any truly cloud native app should be powered by the REST API. In addition, any cloud native app should be able to easily support ten or more clients, meaning it can run on any device or browser. Finally, cloud native apps must be able to move fluidly between cloud providers, so customers aren’t locked into any one platform.
Like any new trend in enterprise tech, the move to cloud native environments will come with a healthy amount of disillusionment from companies that took the plunge, didn’t plan or execute properly and suffered major issues as a result. Adopting cloud native apps will never be quick or easy. But by heeding this advice, organizations can avoid most of the common hurdles.
Always start small with simple, low-risk apps to get accustomed to the process. After that, identify the apps that are the best fit to take cloud native and skip the ones that aren’t good candidates. Be sure that developer, DevOps, NetOps and SecOps teams all have an equal stake in the project. Finally, get comfortable with a good service mesh technology to ensure you can secure your cloud native apps.
Feature image via Pixabay.
