From a business perspective, cloud migrations are driven largely by a desire for flexibility and resilience. When we move systems to the cloud, we expect them to be both more adaptable and more reliable than on-premise solutions. These two objectives are somewhat competitive, however. The Jenga tower is most likely to fall when you are moving a piece. Adding flexibility naturally introduces change which puts stability at risk. (photo credit: pwmag.com)
What we have to say, what you want us to hear.
That’s how our blog works. It’s interactive. Let’s learn together.
With a number of recent high-profile leaks of personal data on Amazon Web Services (AWS) S3 service, it seems like a good time to review the security mechanisms that govern storage and sharing of data from AWS. If your organization uses S3 for storage of PHI, PII, or other sensitive data, you should be aware that failure to properly secure and restrict access and log this information can carry hefty fines and even jail time. Leaking users’ personal data can also be detrimental to your business model. (Photo Credit: Flickr)
Serverless application architectures are still an emerging art form. One of the big challenges serverless architectures pose is traceability and debugging. Because we are dealing with many discrete entities performing as a single cohesive unit, we want to be able to see the impact of those entities on the system as a whole.
A little over two weeks ago, large sections of the internet ground to a halt. Many sites, from Netflix and Spotify to Pinterest and Buzzfeed were unresponsive, during a four-hour outage of Amazon Web Services’ (AWS) S3 – Simple Storage Service. For two of those four hours, AWS couldn’t update the service status from “Service is operating normally” because the status itself depended on the storage service’s operation. Should you trust your data with AWS? Why shouldn’t we start calling S3 the “Sometimes Storage Service?” How could this event be a good thing?