Amazon’s spot market for computing power is set up as an open market for surplus servers. The price is dynamic and depends on demand. So when demand is low, you can get computing instances for rock bottom prices. When you do that you normally set a range of prices you’re willing to pay. If it goes over your top end, your instances get killed and re-provisioned for someone else. Obviously this wouldn’t work for all applications, like a website that has to be up all the time, but for computing power, say to run some huge hedge fund analytics, it might fit perfectly. Continue reading $1000 per hour Servers, Anyone?
Help! How To Become Slightly Happier and Get a Bit More Done
I’ve long overcome that sheepish feeling when browsing the Self-help section at the bookstore. Sure, How to Make Friends and Influence People or the Seven Steps to World Domination in your bookcase aren’t exactly the sort of titles to suggest a deep intellect but I like to keep an open mind when checking out the latest hardcover secret to happiness and prosperity. Basically I try not to diss a book just because it’s got “soup” on the cover.
I will concede that publishers have gone a bit overboard with churning out the number of self-help titles in the last 20 years or so. As with anything that proliferates you’re stuck with having to wade through the swamp of well, BS. HELP! How to Become Slightly Happier and Get a Bit More Done by Oliver Burkeman is ideal for those curious enough about self-improvement but too cool to buy into mind-body-soul mantras.
Could pro-waitering serve up some lessons on web scalability? Observing peak hour dining at a New York restaurant gave us some insight.
I was dining at a restaurant the other day with friends. It was a warm and cozy place, nicely decorated with a long, narrow dining room. The food was scrumptious, yet we were getting increasingly frustrated by the service as the night went along.
With some waiting experience behind me, I could immediately see the problem. The waiters, probably through lack of experience, were making the mistake of doing one thing at a time. They would go to a table, respond to one customer’s request, and go and fetch that item. Back and forth, back and forth they would dart, but always dealing with one request at a time. Continue reading iHeavy Newsletter 84 – Restaurant Scalability
Oracle starts charging for MySQL Add-ons
Exciting news, Oracle just announced commercial MySQL extensions that they’ll be offering paid extensions to the core MySQL free product.
To be sure, this has raised waves of concern among the community, but on the whole I suspect it will be a good thing for MySQL. This brings more commercial addons to the table, which only increases the options for customers. Many will continue to use the core database product only, and avoid license hassles while others will surely embark on a hybrid approach if it solves their everyday business problems. Continue reading Oracle Announces Paid MySQL Add-ons
One of the great things about the Internet is how it has made it easier to put great ideas into practice. Whether the ideas are about improving people’s lives or a new way to sell and old-fashioned product, there’s nothing like a good little startup tale of creative disruption to deliver us from something old and tired.
We work with a lot of startup firms and we love being part of the atmosphere of optimism and ingenuity, peppered with a bit of youthful zeal – something very indie-rock-and-roll about it. But whether they are just starting out or already picking up pace every startup faces the same challenges to scale a business. Recently, we were reminded of this when we watched Inc’s video interview with Birchbox founders, Hayley Barna and Katia Beauchamp. Continue reading Scale Quickly Like Birchbox – Startup Scalability 101
3 ways your MySQL migration project can shake you up
Once a development or operations team gets over the hurdle of open-source, and start to feel comfortable with the way software works outside of the enterprise world, they will likely start to settle in and feel comfortable. Best not to get too cushy though for there are more surprises hiding around the corner. Here are a few of the biggest ones. Continue reading 3 Biggest MySQL Migration Surprises
Check out our followup post 5 More Things Deadly to Scalability
If you’re using MySQL checkout 5 ways to boost MySQL scalability.
1. Object Relational Mappers
ORMs are popular among developers but not among performance experts. Why is that? Primarily these two engineers experience a web application from entirely different perspectives. One is building functionality, delivering features, and results are measured on fitting business requirements. Performance and scalability are often low priorities at this stage. ORMs allow developers to be much more productive, abstracting away the SQL difficulties of interacting with the backend datastore, and allowing them to concentrate on building the features and functionality.
Scalability is about application, architecture and infrastructure design, and careful management of server components.
On the performance side the picture is a bit different. By leaving SQL query writing to an ORM, you are faced with complex queries that the database cannot optimize well. What’s more ORMs don’t allow easy tweaking of queries, slowing down the tuning process further.
2. Synchronous, Serial, Coupled or Locking Processes
Locking in a web application operates something like traffic lights in the real world. Replacing a traffic light with a traffic circle often speeds up traffic dramatically. That’s because when you’re out somewhere in the country where there’s very little traffic, no one is waiting idly at a traffic light for no reason. What’s more even when there’s a lot of traffic, a traffic circle keeps things flowing. If you need locking, better to use InnoDB tables as they offer granular row level locking than table level locking like MyISAM tables.
Avoid things like semi-synchronous replication that will wait for a message from another node before allowing the code to continue. Such waits can add up in a highly transactional web application with many thousands of concurrent sessions.
Avoid any type of two-phase commit mechanism that we see in clustered databases quite often. Multi-phase commit provides a serialization point so that multiple nodes can agree on what data looks like, but they are toxic to scalability. Better to use technologies that employ an eventually consistent algorithm.
3. One Copy of Your Database
Without replication, you rely on only one copy of your database. In this configuration, you limit all of your webservers to using a single backend datastore, which becomes a funnel or bottleneck. It’s like a highway that is under construction, forcing all the cars to squeeze into one lane. It’s sure to slow things down. Better to build parallel roads to start with, and allow the application aka the drivers to choose alternate routes as their schedule and itinerary dictate.
Using MySQL? Checkout our our howto Easy Replication Setup with Hotbackups.
4. Having No Metrics
Having no metrics in place is toxic to scalability because you can’t visualize what is happening on your systems. Without this visual cue, it is hard to get business units, developers and operations teams all on the same bandwagon about scalability issues. If teams are having trouble groking this, realize that these tools simple provide analytics for infrastructure.
There are tons of solutions too, that use SNMP and are non-invasive. Consider Cacti, Munin, OpenNMS, Ganglia and Zabbix to name a few. Metrics collections can involve business metrics like user registrations, accounts or widgets sold. And of course they should also include low level system cpu, memory, disk & network usage as well as database level activity like buffer pool, transaction log, locking sorting, temp table and queries per second activity.
Also: Are SQL Databases dead?
5. Lack of Feature Flags
Applications built without feature flags make it much more difficult to degrade gracefully. If your site gets bombarded by a spike in web traffic and you aren’t magically able to scale and expand capacity, having inbuilt feature flags gives the operations team a way to dial down the load on the servers without the site going down. This can buy you time while you scale your webservers and/or database tier or even retrofit your application to allow multiple read and write databases.
Without these switches in place, you limit scalability and availability.
Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters
Deploying new code that includes changes to your database schema doesn’t have to be a process fraught with stress and burned fingers. Follow these five tips and enjoy a good nights sleep.
1. Deploy with Roll Forward & Rollback Scripts
When developers check-in code that requires schema changes, that release should also require two scripts to perform database changes. One script will apply those changes, alter tables to add columns, change data types, seed data, clean data, create new tables, views, stored procedures, functions, triggers and so forth. A release should also include a rollback script, which would return tables to their previous state. Continue reading 5 Tips for Better Database Change Management
Software development has always made use of libraries, off-the-shelf components that are shared between different projects. These allow you to stand on the shoulders of others and build bigger things. Frameworks do the same thing, they provide a context from which to build on. Ruby on Rails for example provides a great starting framework from which to build web applications, managing sessions in an elegant way. Continue reading 5 Scalability Pitfalls to Avoid
When migrating to the cloud consider security and resource variability, the cultural shift for operations and the new cost model. Continue reading 4 Considerations Migrating to The Cloud