There’s a lot of talk about the cloud and the promise of its elasticity, flexibility and redundancy. Much of the core business functionality historically handled by IT is being slowly offloaded. This is a good thing. For all the IT personnel out there ready to fire your SaaS, IaaS, PaaS providers, don’t worry, take a step back from the ledge, now a deep breath. Your jobs are safe; your cloud vendors are offloading time consuming work so you can focus on your network, work with development to provide stable platforms for your company’s products and service. This is not the end of IT, it is a refocusing and liberation of specific business functions allowing IT to focus on more critical areas.
Cloud services are popping up everywhere; even Email Service Providers, ESPs, are getting the ‘cloud’ treatment. Much has been said, both good and bad, about cloud providers, services and hosted applications; a lot of what has been said isn’t exactly accurate, nor is everyone’s understanding of terms, such as cloud-native, the same. A few things to consider and chew on when you contemplate the cloud and specifically email in the cloud:
- The cloud isn’t less secure than your own in-house network. In fact, much of your business in some form or fashion already leverages the use of the cloud. That’s right. ESPs that leverage traditional, land based hardware have been hacked. However, many cloud ESPs have been hacked? You are using “the cloud” to upload data and content to your ESP in order to launch campaigns. Cloud infrastructure functions off an API or an SMTP bridge. The only data that is “put” into the cloud is public domain anyway, e.g. the TO, HTML Body, TXT Body, FROM etc. In all those cases the information itself is protected by some sort of security measure like cryptography in the form of HTTPs or SSL. This isn’t exactly the PII that you’re really concerned with, is it? You’re not uploading sensitive personal identifiable information (sPII) like credit card and social security numbers to your ESP, are you? No, you’re normally uploading business card or contact data into the system. However, if you need it or If you’re comfortable providing your ESP with sPII data and then blasting it out to 10+ Million people, then why would it matter if the hardware deploying it was land based or sitting in a co-lo? It still passes through the Internet or “cloud” to reach its final destination.
- Lets talk about policies and control. As a consumer you have a choice where you store your money. In the early days people might have simply put it in their mattress (ask your grandparents). However, today people use banks everyday for storing their money. This is a normal and accepted process for all of us today and the government has put in policies like FDIC insurance to inspire confidence. Most of us don’t give it a second thought; banks are where money should be stored and we’ve even gone so far as to authorize the direct electronic deposit of our paychecks. You really can’t physically touch money, not a lot of it anyway, but yet we’re all still ok with storing our money in banks. Why is that? We all know that our banks have created and taken the most cautious measures to ensure that our money is secure and can only be accessed by bank employees or the owner of the account. Most people today use online banking, you never walk into a bank and ask to see the physical thousands you might have, do you? You’ve come to know that a third party can properly secure and handle your hard earned money for you. This is the same kind of paradigm shift that is occurring with cloud providers and the applications they are building.
- Companies that provide cloud-infrastructure/ESP services have as many industry experts as a “land based” ESPs. Quite the contrary, they sometimes have some of the strictest and highest requirements for the companies they allow onto their networks. Just because something is in the cloud doesn’t make it any less important. In fact, for many of us in this space ‘trust in messaging’ is a mission focus and core competency. We all know brands want to ensure the data they trust us with is secure and clean. They have been entrusted with that data by the end users and as such we know brands expect that same sort of treatment they have for it. In fact, many of us today have security standards stricter than SSAE16 or ISO 27001. We know that big brands will require these sorts of things and as such we all use third parties to certify that what we say is what we do in regards to security process and procedures. Ask your provider if they do such things.
- Deliverability doesn’t suffer when working with a cloud based ESP. It is up to the Sender to ensure they have the highest level of opt-in policies, create engaging content and determine the proper cadence, to ensure ongoing good deliverability. Yes, there are a few technology things that we do like DNS, MX SPF and DKIM records, but in today’s world of relevant marketing it is up to the brand/marketer to follow industry best practices and send targeted, relevant email. End user will ultimately decide the final disposition of messages. In fact, I wouldn’t hesitate to venture that deliverability with one of us is going to be much higher and faster. Why? In cloud ESP environments we monitor and track more data points: such as outages, bottlenecks, changes to policies, the internet’s weather patterns if you will. Doing email in-house really only garners you data relevant to you. You don’t have the ability to see what your neighbors are currently going through. It really comes down to statistics: the more data you have the more you can infer from it. If 1 out of 2 dentists pick a gum, how do you know who is right and which you need to choose, but if 9 out of 10 pick the same one then you’re more likely to go that route. Same is true of the data that is created by being in the cloud. The more connectivity and visibility a system has to something the more you can infer from the data produced by said system.
- Claims have been made that cloud based providers rely on increasingly complicated hardware to run their services. This is patently false, if anything, they have greater redundancy when purpose built in the cloud, for the cloud, than a provider who is leveraging a physical, proprietary hardware stack and putting a cloud wrapper around it. Cloud-native application services take full advantage of the cloud’s ability to shift workloads in real-time and are not tied to a single hosting service or provider thus a single point of failure. In most cases, needing backup or standby equipment, for an in-house solution can be costly not only on for the extra equipment, but also the support infrastructure like Internet access and also additional headcount. With cloud, they can live in multiple clouds and deliver capacity that a dedicated stack can’t because capacity in the cloud spins up, on demand, in real time, it doesn’t have to wait on a new box, or blade, or CPUs. The cloud like the Internet are normally built with fault tolerances in mind. Something breaks, something else takes over that responsibility.
- Cloud based messaging does save on licensing fees, liberate IT resources and provide more bang for the sender’s buck because of the overall lower overhead costs.
- Not all cloud providers can scale to meet enterprise needs. The limitations of providers that have cloud washed dedicated stacks make them ideal candidates for the SMB market, but only truly cloud-native approaches can scale infinitely and deliver the kind of capacity and performance required by an Enterprise. It’s important to investigate a potential provider and determine if they are truly cloud-native or cloud-washed as that can make the difference in meeting expectations or under delivering on the best of the cloud.
There are numerous companies in the space claiming to have a cloud-native architecture, but many of them are leveraging specialized and dedicated hardware that is co located and leveraging a “cloud wrapper.” It’s worth spending time investigating potential partners, the difference in architectures really does make a difference.
Don’t Just Send, Deliver! – in the cloud