Cloud infrastructure misconfiguration has emerged as the number one cause of data breaches in the cloud. Rather than application software vulnerabilities, it’s actually misconfigured network settings, firewall rules, storage access policies, and other cloud resources that put our data at most risk. We’ve talked a lot about the risk of cloud misconfiguration and why it’s critically important to have a Mean Time to Remediation (MTTR) for cloud infrastructure misconfiguration that’s measured in minutes, not hours or days. But why are cloud misconfiguration MTTRs more often measured in hours or days? And how many man-hours are teams wasting in their attempts to manage this problem? We work with a wide variety of enterprises using cloud at scale—from federal agencies to Fortune 500...
Two years ago, I wrote a blog post that got some notice, which surprised me. It was a piece about going back to Emacs as my primary content creation tool, first as a CEO, and now as a CTO. A brief recap is that I spent most of my career as a programmer and a software architect, and preferred Emacs as my code editor for much of that time. Reconsidering Emacs was an experiment that I was excited about, but wasn't sure how it would work out. On the Internet, the post was met with roughly equal parts disdain and appreciation, but tens of thousands of people read it, so it seems that I touched on something interesting. Some of the more challenging and funny posts on Reddit and HackerNews predicted that I'd have hands shaped like claws or that I'd have lost my eyesight because I use white...
My previous blog post, Python Mocking 101: Fake It Before You Make It, discussed the basic mechanics of mocking and unit testing in Python. This post covers some higher-level software engineering principles demonstrated in my experience with Python testing over the past year and half. In particular, I want to revisit the idea of patching mock objects in unit tests. Patching External Clients Clients in this post refer to any objects that create side effects, such as disk or network I/O. Consider a class, CloudCreator, that receives messages over HTTP, generates some side effects by creating cloud infrastructure, and sends messages over HTTP in response: import http_client class CloudCreator : def __init__(self) : self.network_client =...
It’s never been easier or faster for companies using the cloud to deploy infrastructure on AWS. That’s the good news. The not-so-good news? You can’t move fast without compromising security, compliance, and control. Well, you can’t unless you automate your cloud infrastructure policies, including compliance and security. Hold that thought for a moment. Here are four common hurdles nearly every organization using the cloud encounters: Inconsistent enforcement of regulatory compliance policies (PCI, HIPAA, NIST 800-53) Uneven use of internal governance policies Uncontrolled shadow IT, ad hoc automation, and tooling sprawl Increased demand for cloud expertise Viewed from a higher level, companies using the cloud need to see all resources running across environments, accounts,...
No matter how you built your cloud—no matter what tools or services you’ve used to provision an application’s infrastructure—you can migrate existing workloads to Fugue easily and securely with no downtime. At AWS re:Invent this week, November 27 - December 1, test out Fugue’s automated infrastructure governance with our team at booth 1600 or explore Fugue’s new migration and enhanced compliance capabilities at www.fugue.co/migrate. By migrating to Fugue, enterprises, agencies, and DevSecOps teams in any organization centralize their control and visibility of systems running in the cloud, while accelerating secure deployments and updates. Human error—typical with scaled, enterprise infrastructure and costly in dollars and consumer trust—is drastically reduced since Fugue highlights...
Twenty minutes or two weeks to spin up your new applications and new product features? Automated care and feeding of infrastructure that requires minimal human intervention or bespoke care and feeding that requires continual attention? The choice seems pretty obvious. Back in 2006, Jeff Bezos was building Amazon Web Services (AWS) to solve a core problem for businesses: undifferentiated heavy lifting. Getting great ideas and applications to market fast is key in holding a competitive edge. If you transform parts of the IT pipeline that require a lot of time, effort, and money—the same parts that every business has to contend with—into fast, easy-to-use, efficient parts, you win. Or, at least, you’re a few laps ahead. Bezos, with foresight to grow AWS into what’s now the largest cloud...
This article was first published in DZone's Cloud Zone on April 3, 2017. The repercussions of recent cloud outages—AWS’s S3 crash and Azure’s Active Directory cascading failure—linger in IT departments and manifest in revenue loss. But, the bigger story is that the next outage is around the corner—unpredictable, coming to get us on a random Tuesday. Whether businesses are using cloud providers, on-premise data centers, or hybrid setups to host web services and backends, infrastructure failures are a fact of life and have to be on our radars as a matter of routine. This makes architecting for failure and for the future, from the start, among the most pressing imperatives for business IT departments. The next five years will see the rise and democratization of centralized control...
Fugue uses Python extensively throughout our cloud security SaaS product and in our support tools, due to its ease-of-use, python security, extensive package library, and powerful language tools. One thing we've learned from building complex software for the cloud is that a language is only as good as its debugging and profiling tools. Logic errors, CPU spikes, and memory leaks are inevitable, but a good debugger, CPU profiler, and memory profiler can make finding these errors significantly easier and faster, letting our developers get back to creating Fugue’s dynamic cloud orchestration and enforcement system. Let’s look at a case in point. In the fall, our metrics reported that a Python component of Fugue called the reflector was experiencing random restarts and instability after a...
Slack is amazing. We, here at Fugue, are an engineering-centric organization distributed across three offices with several developers located in one-off locations around the world. Having a real-time, easily accessible hub for communication has helped us stay gelled as a community. It’s a technical resource, a sounding board, and a water cooler all in one. But Slack is not all unicorns and rainbows. Like many other organizations, we’ve discovered that replacing email (for the most part) with Slack has brought some challenges. As the company grew, the volume of discourse on Slack became unwieldy. Channels propagated and we were faced with Slack bloat. The problem was not just one of noise, it was one of uncertainty as well. What Kind of Uncertainty? You see, important conversations...
Years—no, decades—ago, I lived in Emacs. I wrote code and documents, managed email and calendar, and shelled all in the editor/OS. I was quite happy. Years went by and I moved to newer, shinier things. As a result, I forgot how to do tasks as basic as efficiently navigating files without a mouse. About three months ago, noticing just how much of my time was spent switching between applications and computers, I decided to give Emacs another try. It was a good decision for several reasons that will be covered in this post. Covered too are .emacs and Dropbox tips so that you can set up a good, movable environment. For those who haven't used Emacs, it's something you'll likely hate, but may love. It's sort of a Rube Goldberg machine the size of a house that, at first glance, performs all...
.png?width=36&height=36&name=linkedin%20(1).png){kind=small}
.png?width=36&height=36&name=twitter%20(1).png){kind=small}
