Here at Engine Yard we're always trying to make your deployment experience easier: easier to provision instances, easier to deploy, and easier to manage your infrastructure. Historically, part of that process involved the creation of an AWS account specifically for your individual use. However, with more and more companies adopting cloud-based architecture, more and more Engine Yard clients already have their own AWS account; whether it be used for massive numbers of instances, or just for S3 storage. We've heard your feedback and we're happy to announce that you can now bring your own AWS account to our platform.
Blueprints have been a long requested feature on Engine Yard Cloud, but what exactly are they?
In the case of Engine Yard Cloud, a Blueprint is a way to describe an instance configuration for an environment, including the number, flavor,and volume sizing for all application, database and utility instances. This allows you to easily recreate environments without going through the tedious process of filling out the Boot Instances form each time.
You’ll find the Blueprint Manager page in your Tools drop down on the Cloud dashboard. From there, you can view, edit, or delete any existing Blueprint as well as create a new one. You may also notice that you have some auto-saved Blueprints. When all instances in an environment are stopped, the dashboard will automatically generate a Blueprint for the current configuration and save it for you.
Calling all Ruby enthusiasts! Calling all Ruby enthusiasts! Engine Yard will be at RubyConf 2015 in San Antonio, and we are looking forward to seeing you. It’s been so long? My how you’ve grown. Us? Oh we’ve been great! We’ve been working hard to improve the Engine Yard cloud platform to make it easier to deploy and more feature rich. Engine Yard has always had a strong history of working within the open source community, be it supporting great ruby applications, contributing to open source projects, or investing in new open source technologies, like Deis.
We are focusing on bringing some new features to the Engine Yard platform, some that have just been released and some that are in the pipeline. We’ve integrated our Bring Your Own Credentials system to Engine Yard Cloud, enabling customers to connect their own AWS account while still being able to use the simplicity and ease of the Engine Yard platform. Got AWS credits? Bring your own credentials! Getting a better deal on AWS instances? Bring your own credentials! Want to use AWS free tier but still have the simplicity of deploying in minutes? Bring your own credentials!
Another feature we are bringing to Engine Yard Cloud is the idea of environment blueprints. With blueprints you’ll be able to quickly spin up a replicable environment blueprint that can be easily used for AB testing or in case of a catastrophic failure, simply select the blueprint and your environment will start rebuilding as it was.
Engine Yard is also bringing per environment support and updated stacks to the Engine Yard platform later this year. Allowing our customers to get the premium support they need for their critical environments while saving on their development environments. As well as updates to our tech stacks to bring new stable version updates for our customers.
So, if you happen to be attending RubyConf, swing by the booth to check out some of our swag. We’ll have some really sweet old school shirts, koozies, and some special stuff for our dedicated Engine Yard customers. Including high-fives, because who can pass those up?! Myself, support members, and engineers will be attending RubyConf, so stop by our booth and say hi, grab a t-shirt, or let us know what you’d like to see in the future. Here’s to another great RubyConf!
I am happy to announce the Engine Yard Cloud platform has successfully received a Service Organization Controls (SOC) 2 Type II report with a positive opinion from the third party auditors.
Engine Yard’s SOC 2 report is a measure of the rigor applied to our systems, policies, services, and management processes. By demonstrating compliance with the industry security standards, Engine Yard is providing even greater assurance to customers that it is safe to run their applications on the our platform.
Engine Yard is committed to security and compliance. If you are an existing customer, you can open a support ticket and we will share the report with you. If you are considering hosting your application with Engine Yard, please contact a Sales Team representative.
Engine Yard can also host your Payment Card Industry Data Security Standard (PCI DSS) or Health Insurance Portability and Accountability Act (HIPAA) app. Our support team works diligently put the necessary security controls in place to make sure our customers are compliant. You can learn more about our efforts by reading our white papers on PCI here, and HIPAA here.
If you have questions about security and compliance (procedures or controls) in place at Engine Yard, please contact support via the ticketing system or IRC.
When a process has side effects that need to be executed only in certain situations, this functionality can be layered onto an existing operation using Decorators. A Decorator takes an object and wraps auxiliary functionality around it, letting you add on what you need when you need it and keeping the core procedure untouched.
Let's imagine a Service Object that generates report cards for each student in a class. A teacher can generate these report cards at any point, but there are some situations where those report cards should be mailed to the student’s parent.
One way to address this would be to have two separate Service Objects, GenerateReportCards and GenerateReportCardsAndEmailParent, but this creates duplication and is hard to maintain when there are many cases with many conditional steps.
Another way would be to chain separate services, such as:
This isn't bad, but it relies on the return value from the Service Object to be usable for the subsequent process. Additionally, the same process may need to happen in both procedures, such as generating the HTML for the report card.
This problem calls for a Decorator, which targets a specific method of the object being decorated and wraps it with additional procedures, allowing us to tap into an existing operation and add functionality. So, for this example, our Service Object that will be decorated looks like this:
We could create a Decorator object that accepts an instance of the Service Object as its argument and returns that Service Object with the specified method wrapped with the added functionality.
One key goal of the Decorator pattern is that the returned object is the same object as the input object—both in terms of identity and API—but with an altered property. So the following should be true if the object is decorated properly:
With this pattern in practice, we can layer on any number of Decorators that decorate any number of methods on the original Service Object:
When testing a Decorator, it is wise to test that the method is both decorating the original object properly and that the auxiliary method (or methods) are performing the right actions. A reasonably comprehensive test suite for the EmailReportCardToParent Decorator above could look like this:
Decorators are useful when you want to layer on functionality to existing operations without modifying those operations for all scenarios. This means greater code portability and reuse, which is always valuable.
What are some of your favorites of the patterns I've covered here? Are there others that I didn't mention that you've used?
The post was originally written for the Crush & Lovely Blog in 2012 and has been lovingly brought up-to-date for Engine Yard by Michael Phillips, the original author. Special thanks to Justin Reidy and Anisha Vasandani for help with the original.