Spring Product Updates »
Created at: 03.05.2012 01:16, source: Engine Yard Blog, tagged: Product
Happy spring! While we’re all gearing up for baseball (Go Giants!) and warmer weather, I just wanted to take a quick moment to highlight some of our recent updates to Engine Yard Cloud.
New Instance Size
We are also very happy to announce that today, we have released Amazon’s latest Medium instance on the Engine Yard Cloud product. Pricing for the new Medium instance (m1.medium) is $0.24/hr. You can find all of our pricing information here. More in-depth information about the instance sizes can be found here.
More Ruby, More Data
In the last couple of months, we’ve also released Ruby 1.9.3 and PostgreSQL 9.1 into GA. We’ve received a lot of great feedback from customers using these and we think you’ll be as thrilled as they are to use them.
JRuby and Node.js Updates
We're definitely ramping up our stack. Back in January, we upgraded Node.js 0.6.1 to 0.6.8. It is now installed from EY Portage and uninstalled from /opt/node. And more recently, we upgraded JRuby to 1.6.7 from 1.6.6. Check out more information about it here.
Have any questions about these updates? Go ahead and give us a shout!
more »
Orchestra Elastic Apps For Everyone »
Created at: 07.02.2012 21:24, source: Engine Yard Blog, tagged: Orchestra Platform php Product auto-scalling elastic orchestra release
It's been a long time coming, but we've finally made our auto-scaling elastic app capability available to everybody on Orchestra. Previously, this was only enabled on an account-by-account basis. An elastic app is smart enough to scale up when your traffic increases and scale down when your traffic decreases. You don't have to do anything, and you can deploy this sort of app right away. Sign in to your account now and select "Deploy An Elastic App" from the sidebar.
So how exactly do elastic apps differ from basic apps? Well, our basic apps offer you a single fixed amount of resources. For small apps, or staging versions of your production apps, this is fine. But for bigger things that need to handle a variable load, we have elastic apps. These apps start with one scale unit and increase by one scale unit at a time as your resource usage increases. As resource usage decreases, we scale you down by one scale unit at a time too.
But what's a scale unit? One scale unit provides up to 1.2 GB RAM and 2 Dual Core CPUs burstable to 1GHz. Behind the scenes, this may be provided by one or more server instances. We do this to maximize the redundancy of your app, and its fault tolerance to network outages, restarts, and other low-level problems that you shouldn't have to worry about. This ability to recover from problems ensures that your apps are auto-healing, as well as auto-scaling.
What does this mean for your app? Well, on a day to day basis, the app will run with as many scale units as it needs to function properly. You don't have to guess at what this might be, because our system works it out for you. And when someone links to your site in the middle of the night, and you experience a traffic peak, we scale you up to handle the increase in resource usage. And then we scale you back down again when traffic returns to normal.
How should you write elastic apps? Well, if you want to take advantage of our auto-scaling and auto-healing, your apps will need to embrace a shared-nothing architecture. In the general case, that means you need to design your app so that individual instances of it can be killed off and respawned at any moment. This means keeping all your data in separate database like MySQL or MongoDB, which we provide addons for. And it means that you need to write file uploads to a shared storage service, such as Amazon's S3. But whatever you do, don't write anything important to local filesystem, or it will be lost when we auto-scale or auto-heal.
If you have any questions about this, or about how best to build elastic apps for Orchestra, please get in touch. At the moment, apps are capped to eight scale units. If you need more than that, you can request a higher cap by submitting a support ticket. In the future, we plan to add more intelligent ways of handling and safe-guarding scale unit allocation. We'd love to hear your thoughts. And if you haven't seen it already, check out our revamped pricing model.
more »
MySQL 5.5 is in Beta »
Created at: 06.12.2011 19:55, source: Engine Yard Blog, tagged: Product ruby
A few months ago we launched an alpha release of MySQL 5.5. Today we are releasing a more robust version as a public Beta, which includes fixes and enhancements based on customer feedback. You can select MySQL 5.5 from your environment and install the Percona Server v5.5.13. The Percona build is an enhanced drop-in replacement for MySQL that allows you to run queries with greater speed and consistency.
Benefits of Upgrading
MySQL 5.5 delivers significant enhancements that enable you to improve the performance and scalability of your web applications. Some reasons to upgrade are:
- InnoDB as default storage engine: Starting in MySQL 5.5, InnoDB is the default storage engine. MySQL 5.5’s InnoDB 1.1 storage engine is re-architected and has many performance and scalability features.
- Improved multi-core performance: The database and its InnoDB storage engine have been enhanced to provide optimum performance and scalability when running on the latest multi-CPU and multi-core hardware and operating systems.
- Improved recovery performance: One of InnoDB's great strengths is its ability to reliably recover data after any type of crash that affects the database. But, this cleanup and checking makes the next restart longer. InnoDB 1.1 has improved the algorithms for recovery to provide faster uptime after a crash.
See the MySQL Documentation for additional information.
Important! MySQL 5.5 on Engine Yard Cloud is a Beta feature. Always test in a development or staging environment before using this feature in production.
Available Upgrade Options
Dump and Restore
Best for: Small to medium data sets
This entails creating a new environment that is running the MySQL 5.5 database version and restoring a dump from the original environment to it. It requires your application to be down (or at least not servicing database requests) for the duration of the dump from the original environment and the restore to the new one. The size of your database matters; the more data you have, the longer it takes to dump and import it on the new database. Instructions on dump and restoring backup files can be found under Scenario 2 in our Database Documentation site.
If you know or suspect that the dump/restore upgrade will take too long (from prior testing or from the size of your database), then contact our Professional Services team to inquire about an assisted in-place upgrade of your existing environment(s).
more »
Improved DB Slaves, with love from EY PDX »
Created at: 03.12.2011 02:21, source: Engine Yard Blog, tagged: Product Technology
It may be cold and rainy but our database enhancements are hot!
We’re happy to announce that Engine Yard Cloud database support just got better! We’ve made several database functionality improvements that make scaling your application easier than ever. You can now provision slave instances that are smaller or larger than your database master. Also, you have new snapshot and volume options when creating database slaves. You can provision slaves with a larger storage volume than their master, and soon you’ll be able to use an existing snapshot to speed up slave creation.
Larger DB Volumes for Database Slaves
It is now possible to provision a database slave with a larger volume size than your db master. This, again, makes it easier to upgrade to a larger db master (or specialized slave!).
There is a caveat with regard to db volume increases: the db partition needs to be re-sized after the instance boots. If your stack is up-to-date, this will happen automatically. If not, you can click ‘Upgrade’ or have support enlarge the db partition for you.
Larger Instance Sizes for Database Slaves
It is now possible to provision a database slave using a larger AWS instance size than its current master. This lets you add a beefy slave, allowing you to get one step closer to that larger database master you’ve always wanted.
There are some restrictions (it is the real world, after all). When using PostgreSQL you can't use a snapshot created on a 32-bit instance when building a 64-bit instance and, vice-versa. Don’t worry, we won’t let you accidentally make a mistake. The instance sizes you are offered are the ones that will work with your database master.
Smaller Slaves Also Possible
Save $$! You can now boot a database slave using a smaller instance size than the database master. This is particularly handy if you just want a smaller slave to back-up from, but not serve reads or be a candidate for failover.
Not all combinations work equally well, however. We don’t recommend creating a Small replica for a High Memory 4XL. Here are our recommendations for minimum sizes. Please refer to the documentation for more information.
|
Master |
Minimum Recommended Replica |
|
Small |
Small |
|
High CPU Medium |
Small |
|
Large |
Small or High CPU Medium |
|
High Memory XL |
Large |
|
XL |
Large or High Memory XL |
|
High CPU XL |
High Memory XL, Large, High CPU Medium |
|
High Memory 2XL |
High Memory XL or XL |
|
High Memory 4XL |
High Memory 2X |
PDX Update
We hope you are as excited as we are about these new features. The PDX team worked tirelessly to get this very important feature out in record time. Speaking of PDX! We just passed our three-month anniversary at the new office space on December 1st. It’s been a very busy few months, with a steady stream of visiting SF developers, designers, and guests dropping in to work from the comfort of our couches.
We’re still looking to round out the PDX office with a couple of stellar support peeps. Support Engine Yard style, aka people who are passionate about web technology, love to solve different problems, and get pleasure in helping others. We (PDX developers) are particularly looking forward to having support staff on site, to easily chat about what our customers might most want and need.
more »
Introducing the Early Access Features page »
Created at: 02.12.2011 02:01, source: Engine Yard Blog, tagged: Engine Yard Cloud Product Uncategorized
Last week, we announced Node.js support as part of our Labs program. At the beginning of this month, we also released early access to Ruby 1.9.3, and our data team is doing great work expanding our stack.
Previously, we asked you to sign up through various pages, and you would have needed to wait for us to grant your access. Today, we’re ready to give you easier control of these features. From the Early Access Features page, you’ll be able to manage these new features on your own. When you visit your account settings, you will see a button at the bottom of the page.
Now, using Engine Yard Labs and Alpha features will be as easy as turning on a switch!
For our current features in early access, you can still use our sign up pages to have them enabled for you if you choose, but we think this will make it much easier for you to try out. As always, feel free to let us know what you think at our feedback Google Group!
more »
Tag cloud
Categories
Links
Blogs: 43
Posts: 2516