Modernizing IT with Cloud Native Patterns – Part 2
May 1, 2018
4 minute read
This content originally appeared as a whitepaper on InsideTrack. This three-part blog series will explore the advantages of going cloud native and offer tips for organizations that are ready to modernize their IT system. Part 2 discusses laptop management patterns, loose coupling, SSO as a default, self-service, and collaboration. (If you missed Part 1, which explored the term “cloud native” and zero trust network architecture, check it out here.)
Laptop management patterns
While it is neither possible to migrate physical laptops nor elegant today to move Windows or MacOS into the cloud, it is possible to transition to cloud native management for end user laptops.
Legacy anti-patterns and cloud native patterns
On any given day, according to Lastline Labs’ analysis, much of the newly detected malware goes undetected by as many as half of the antivirus vendors. Rather than attempt a real-time evaluation of every possible piece of software, file addition, or change against an ever-growing list of threat signatures, cloud native architecture denies by default. While whitelisting has come up as a possible suggestion, not until mobile phones and Chromebooks was it successful.
Chromebooks
Chromebooks are unfortunately the only cloud native personal computer in widespread use today. Fortunately, they adopt all of the cloud native patterns and result in a secure, low-cost laptop with long battery life. The further along in a cloud native journey you are, the easier it will be to adopt Chromebooks for end users. The more widespread the use of cloud native personal computers is in the organization, the more resilient the organization will be to ransomware and other malicious attacks.
Loosely coupled
Whether or not a service has a public API, it’s important to strive for a loose coupling of services. While in the short term a service may seem easy or efficient, in the face of the speed of change we’re seeing today, all organizations are best served by planning for eventual service transitions.
Loose coupling is an understood advantage of microservice architecture. Likewise, there is an analogous advantage to having a loosely coupled stack of cloud native software. Loose coupling includes weighing the cost benefits of making yearly vs. monthly commitments. Monthly commitments are recommended when possible as they allow for greater flexibility. But if the savings is significant and it’s clear you won’t have a superior alternative or bandwidth for another migration within the year, making a year-long commitment could be justified.
With the rate of innovation, displacement, and disruption, there is no way to confidently choose a technology that is not at risk of becoming outdated by better, cheaper, faster, or paradigm-shifting capabilities within twelve months. Given this reality, making two- or three-year commitments even with the promise of a significant discount should generally be off the table. While it may be somewhat challenging to know ahead of time, it’s worth attempting to size the effort required to onboard/offboard a given service.
As always, use caution when reviewing contracts for hidden exit clauses that require additional and/or written notice of cancellation. The advantages of loose coupling not only allow for a rapidly evolving internal stack but also facilitate faster and simpler acquisitions and mergers.
Public API
There is no more powerful architectural enablement of loose coupling than a public API. Why is something as technically specific as having a public API such a useful differentiator when evaluating solutions? First, it’s a likely indicator of cloud nativity as the vast majority of cloud native SaaS options have a public API. It’s also an indicator (though not a guarantee) of attention and rigor of security, because having a publicly accessible API requires good security practice and monitoring to avoid exploit and compromise. With a stack of services with increasing API functionality, it becomes more possible to automate internal processes, quickly wire up integrations between other providers, or even potentially facilitate a rapid pivot to a more robust or competitive service when it’s warranted.
Single sign-on as default
SSO integration has matured enough to bring into question the use of a separate dedicated tool for SSO. Organizations that are currently locked into on-premise Active Directory as the primary authentication mechanism or other similar legacy and on-premise technology may need a third-party SSO integration to bridge or fill gaps during a transition phase. Both OAuth and SAML are increasingly standard components of SaaS solutions and also a good indicator of a cloud native solution.
Self-service
While security or the particulars of a given process often require a ticketing system with a one-for-one ticket-to-human interaction ratio, a growing pattern within cloud native systems is a decidedly self-service orientation. This orientation flows naturally from relatively small teams who have built tools that otherwise scale well until a process requires human interaction.
Even today in large enterprise organizations who’ve outsourced their helpdesk, you can find a 24-hour turnaround for tasks as simple as adding a distribution group or a shared folder. Moving to a self-service orientation requires those familiar with a traditional IT process to learn to trust both end users and cloud native solutions that increasingly remove insecure configuration options. While high security or otherwise highly sensitive tasks may not lend themselves to self-service orientation, often the efficiency gains are matched by end user satisfaction because end users are empowered to move as fast as they can. While self-service won’t eliminate the need for a helpdesk or SaaS administration, employees will be happier with the increased velocity and empowerment self-service brings.
Collaboration
Legacy systems had to assume not everyone could be connected to the internet. Even where online editing was possible, it required checking out and locking access to a single user to avoid the eventual merge conflicts.
Cloud native systems assume everyone is online. Real-time collaboration allows for an order of magnitude improvement in speed and efficiency in collaboration. Instead of taking hours, days, or weeks to collect feedback from multiple users, with cloud native it is as simple as publishing a deadline and sharing access. Making comments, suggestions, or edits in real time optimally gathers the best thinking from multiple contributors in a fraction of the time and effort.
Stay tuned for Part 3 of our blog series!
