We at Luminal are launching our new vision for computing: Fugue. Fugue embodies a set of core computing patterns that rely upon: Automating the creation and operations of cloud infrastructure through a no-touch runtime environment. This uses an active infrastructure OS under users’ control and within their environment. Short-lived compute instances that are created and destroyed by this infrastructure OS, resulting in higher fidelity systems that optimize performance and cost. Simplification of compute instances to reduce vulnerability. You may recognize in these patterns the meme of “immutable infrastructure”—the idea that computing infrastructure elements not be changed through in situ repair or upgrade—but rather that they be purposefully thrown away and replaced in order...
In two previous posts, I explored the concepts of "Minimum Viable Clouds" and "More than Minimum Clouds." To recap, a Minimum Viable Cloud must: be an SOA hide implementation be fully automated be a utility have global fault tolerance be Opex A cloud that is More than the Minimum must: promote stateless, distributed compute have asynchronous messaging have data persistence as a service Future clouds are those that move past the performance and composition aspects of cloud-native applications into new territory in efficiency and security. There are many possible futures for cloud, and likely several that will be realized. At Luminal, we have a vision of cloud computing that provides significantly more control, efficiency, and security than is currently...
The M in MVC (Minimum Viable Cloud) implies that there are additional capabilities in a mature cloud implementation beyond those outlined in our previous post, which introduced MVC. Recall those sine qua non MVC requirements: Clouds are APIs Clouds are SOAs Clouds Hide Implementation Clouds are Fully Automated Clouds are Utilities Clouds have Global Fault Tolerance Clouds are Opex Additional capabilities that constitute fully developed cloud ("C") exist in areas like service offerings - having more of them, such as object storage or noSQL databases. But, metaprogramming capabilities that allow you to compose and orchestrate systems across resources are the centerpiece of C. Let's get specific. C>M Clouds promote stateless, distributed compute Cloud-native...
Every time a new, hot technology appears on the scene, many companies with old, boring technologies slap a sticker on the front of their product, proclaiming it to be a torchbearer for the new tech. It's something of a parlor trick. Certainly this has been the case with cloud technologies. As a result, there's a need to differentiate things that actually deliver the promised benefits of cloud from things that are just cloudwashed. After a decade of building service-oriented architectures and cloud products for AWS and others, I've had time to reflect on how to distinguish the real from the marketed. Others have taken a crack at this, but explanations that begin with the developer's perspective - the developer who builds and uses new systems on cloud infrastructure - are not especially...
The greatest opportunity for Amazon Web Services to grow in the short term lies in convincing large enterprises to move their computing into the cloud. Given the sheer volume of enterprise on-premise installations, AWS is counting on the incremental, and in many cases wholesale, migration of legacy operations to the cloud to fuel the next phase of its explosive growth. But despite this being the year of the enterprise at this month's AWS re:Invent conference, the drumbeat of AWS as a fertile ground for startups remained loud and steady. Everybody understands the rationale for cloud computing: no capital investment, near infinite scaling, and a constellation of ancillary services to address security, analytics, storage, and other requirements. It is now possible to build a substantial...
The Luminal team headed to Las Vegas last week to attend the second Amazon Web Services (AWS) re:Invent conference. As we're actively developing on AWS, we were eager to learn about new AWS services offerings, explore the AWS ecosystem of developers, Independent Solution Vendors (ISV) and Systems Integrators (SI), and connect with AWS staff to learn more about how we can build smarter and faster. The level of energy and excitement at re:Invent was something none of us had experienced at a software conference before. There are likely many reasons for this, but we primarily attribute it to the fact that AWS has established itself as the undisputed frontrunner in cloud with significant momentum among developers and ISVs. Attempts by competitors to change the subject with bus...
In the lasttwo posts in this series, I illustrated how an unconsidered VPC architecture can lead to inefficiency and poor resiliency. In this post, I'll show how to get to an efficient, secure and highly resilient VPC design. Keep in mind that there are many successful patterns to building VPC and this is only one of them, but is in most cases the most logical starting design. In order to succeed in creating high fidelity, resiliency and efficiency, you'll want to: keep things simple, design for multi-AZ, and use Security Groups Keep it Simple There is a lot of complexity in typical LAN designs in on-premise data centers, and for good reason. With on-premise networks, subnets and address ranges become the focus for rules and filtering. This is not only unnecessary in most...
Dennis, an engineer at Complicado Corporation, has decided to try porting his company's web application to AWS. Dennis does a little reading and realizes that he should use VPC so his database server is in a private subnet and hits the AWS web console. He fires up the Start VPC Wizard. Scanning the options, Dennis sees "VPC With Public and Private Subnets". Cool - Dennis' work is done! He leaves the defaults alone and ends up with a network that looks like this: Dennis starts creating EC2 instances and notices that they are instantiated into a particular subnet, so Dennis drops his web server into his Public subnet and his database server into Private. Dennis slaps an Elastic IP onto his web server, creates some DNS entries in Route 53 and is off to the AWS races. Now Dennis's...
Most of the features of Amazon Web Services (AWS) are low risk in terms of changing your mind later. Don't like an EC2 instance type? Just stop it and start it with a new type. Want a larger EBS volume? Simply snapshot the current one and create a larger volume from it. The flexibility and low costs of errors are some of the great features of the AWS platform. However, one place where you really need to get things right from the start on the AWS platform is in your Virtual Private Cloud (VPC) design. Unfortunately there isn't a lot of wisdom imparted through the defaults or documentation provided. The purpose of this post is to lay out some best practices so you won't find yourself up a creek later. If you've already gone partway up a creek, you'll be fine - AWS is a pretty agile...
.png?width=36&height=36&name=linkedin%20(1).png){kind=small}
.png?width=36&height=36&name=twitter%20(1).png){kind=small}
