Category Archives: Uncategorized

Why AWS Summit is free but Oracle World costs $2650

ellison exadata

Attending Oracle World a half dozen times in the past decade, I can say it’s quite an event. All of Moscone center plus local hotels & many streets are taken over to host the event. As an author of Oracle & Open Source on O’Reilly I’ve snagged comped tickets, otherwise the conference would be far out of reach.

Amazon has their AWS Summit, which it turns out is free. What does this highlight about the very different cultures & business models of the two firms?

Join 17,000 others and follow Sean Hull on twitter @hullsean.

1. Two iconic founders

We’re hearing about Jeff Bezos in the news constantly these days. With his purchase of Washington Post, and his huge play in cloud computing with Amazon Web Services, it’s hard to avoid him.

Meanwhile Larry Ellison recedes somewhat into the background. Last I heard he won the America’s Cup Yacht Race, but only after various cheating scandals subsided & a crash besides. But the story of Oracle has always been a wild wild ride.

bezos reinvent

If you’re interested to learn the sordid history of Oracle corp, look no further than Mike Wilson’s The difference between god* and Larry Ellison. Hint: God doesn’t think he’s Larry Ellison.

Also: Why Oracle Won’t Kill MySQL

2. Two billion dollar companies

If you look at the two firms as I did on February 7th 2014, you’ll see their Market Cap’s are close.
ORCL at 167.26b and AMZN 165.83b. Recall though that Amazon has only been around since 1994, while Oracle’s been tormenting us since 1977!

Related: Are SQL Databases Dead?

3. Two sales-heavy conferences

Both companies have conferences. Oracle’s Open World is a week long affair bring countless success stories and case studies, but all vetted carefully to present a strong & compelling marketing message. Less technical, these sessions speak to the high level strengths of the platform and components.

Amazon’s Re:Invent conference though a smaller one-day affair, also uses a similar model. Bring a lot of marketing muscle to bear, and sell sell sell.

They are both wonderful for what they are, but often gloss over the technical details. They understate difficulties, and troubles as well as Implementation challenges and costs too. Though through all this they make great networking events.

Read: Why AirBNB Didn’t Have to Fail

4. Fat margins or Thin?

There are two sort of big models for selling software.

First there is the Oracle model, send in a high profile sales team. Wine & dine the client, sell hard. Win them over, and get ’em on Oracle. Sell them with add-ons, and software lock-in. Once that’s complete it’s too painful to leave Oracle. That’s when you squeeze. Customers may learn too little too late. For customer businesses, shareholders may begin to regret their decision to go with Oracle. Or it may be buried at the bottom of a balance sheet.

One things for sure, shareholders of Oracle surely benefit from Larry’s model. You become a multi-billion dollar industry unto yourself, and even the likes of spinoffs like Salesforce.com and competitors like Workmarket can’t slow you down much.

Amazon’s model is quite different. Here you kill your competitors by squeezing your own margins. Your company culture is about austerity as opposed to exhuberance. And you win by being first to market, and relentless price competition.

Check this: Why High Availability Is So Hard to Achieve

5. Who wins in Bezos’ world? Customers!

An Oracle Openworld package for 2013 would set you back $2650.

AWS Summit is free. That’s right, it will cost you zilch to attend. Contrast this with Oracle World, which besides also being largely a marketing conference that sells to customers, and which is in part funded by marketing budgets, it is by no means free.

Customers win big in the world Bezos is creating.

Check this: Why High Availability Is So Hard to Achieve

Get more. Scalability. Startups. Innovation. . Monthly tips and exclusive content. Our latest When Clients Don’t Pay

How to deploy on Amazon EC2 with Vagrant

vagrant logo

I recently wrote up how to use Terraform to deploy on Amazon EC2. Check it out!

Join 32,000 others and follow Sean Hull on twitter @hullsean.

Why do I want Vagrant?

Vagrant is a really powerful tool for managing virtual machines. If you’re a developer it can make it push-button simple to setup a dev box on your laptop. It manages the images, and uses configuration files to describe specifics of your machines.

In the amazon environment, you can deploy machines just as easily as on your desktop. That’s pretty exciting for those of us already familiar with Vagrant. With that I’ve provided a simple 7 step howto for doing just that!

Also: Are SQL Databases Dead?

1. Use the Mac OS X installer

Fetch your download file here:

Vagrant Installer Downloads

Run the installer. It should do the right thing!

Also: Why Oracle Won’t Kill MySQL

2. Install the vagrant-aws plugin


$ vagrant plugin install vagrant-aws

Also: Bulletproofing MySQL Replication with Checksums

3. Fetch a vagrant box image

Box images vary depending on your “provider” which is vagrant-speak for the environment you’re running in. For aws, they’re some simple json files that tell Vagrant how to work in that environment.

The creator of the plugin has provided a dummy box. Let’s fetch it:


$ vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

This command is straight out of the readme. What does it do? Take a look:


$ cd /var/root/.vagrant.d/boxes/dummy/aws

$ cat metadata.json
{
"provider": "aws"
}

There’s also the info.json file which looks like this:


$ cat info.json
{"url":"https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box","downloaded_at":"2014-01-14 17:42:33 UTC"}

There’s not a whole lot going on here. If you’re deploying VirtualBox VMs with Vagrant, you’d see a VMware4 disk image. But with Amazon, it stores it’s own AMIs on S3, so Vagrant simply fetches them and runs them for you.

Related: Intro to EC2 Cloud Deployments

4. Configure Vagrantfile

Create a directory to hold your vagrant metadata. This would be the name of your machine:


$ cd /var/root
$ mkdir testaws
$ cd testaws
$ vagrant init

Edit the file as follows:


Vagrant.configure("2") do |config|
# config.vm.box = "sean"

config.vm.provider :aws do |aws, override|
aws.access_key_id = "AAAAIIIIYYYY4444AAAA”
aws.secret_access_key = "c344441LooLLU322223526IabcdeQL12E34At3mm”
aws.keypair_name = "iheavy"

aws.ami = "ami-7747d01e"

override.ssh.username = "ubuntu"
override.ssh.private_key_path = "/var/root/iheavy_aws/pk-XHHHHHMMMAABPEDEFGHOAOJH1QBH5324.pem"
end
end

If you’re familiar with the Amazon command line tools, you’ve probably setup environment variables. Otherwise these may not be familiar to you, so lets go through them:

Your access_key_id and secret_access_key are two pieces of information Amazon uses to identify your instances and bill you. Those are unique to your environment so keep them close to the vest. Here’s how you create them or find them on your aws dashboard.

The keypair_name is your personal SSH key. You may have one on your laptop which you use to access other servers. If so you can upload to the amazon environment. If not you can also use the dashboard to create your own. Whenever you spinup a server, you can instruct amazon to drop that key on the box in the right place. Then you’ll have secure command line access to the box, without password. Great for automation!

Next is your AMI. This is an important choice, as it determines the OS of the machine you’ll spinup, and many other characteristics. You can go with a Amazon Linux AMI but I quite like the Alestic ones from Eric Hammond. Trusted & reliable.

Looking for an ubuntu AMI? Try this ami locator tool.

Check this: 8 Best Practices for Deplying MySQL on AWS

5. Startup the box

Starting an instance once you’ve configured your Vagrantfile is pretty straightforward.


$ vagrant up —-provider=aws

Related: How to autoscale MySQL on Amazon EC2

6. Verify in the Amazon dashboard

Jump over to your amazon dashboard with this link. If you’re logged in already, that will take you to your EC2 instances. You should see a new one, based on the parameters in your Vagrantfile.

Read: Why devops talent is in short supply

7. Login to your Amazon instance

Last but not least, you’ll want to login. Note I’m explicitly specifying my SSH key here. Your path may vary…


$ ssh -i ./iheavy.pem ubuntu@ec2-50-220-50-40.compute-1.amazonaws.com

Also: 5 more things deadly to scalability

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

What I learned from Ryan Holiday

trust me ryan holiday

Join 16,000 others and follow Sean Hull on twitter @hullsean.

Picked up Ryan Holiday’s Trust Me I’m Lying, Confessions of a Media Manipulator recently. Boy is he good at what he does. This book reads like a howto on free PR & marketing. It also of course serves to protect those who might want to be a bit more informed.

1. Yellow journalism is back

A brief dig into the history of journalism uncovers a festering mess. Before newspapers like NY Times were sold by subscription, most were sold on the street. That meant the echo of a screaming headline had to sell the paper. Sound familiar?

Apparently these yellow papers always had screaming headlines, lots of pictures, “anonymous” sources plus frauds & faked interviews. Anyone seen this before on the interwebs?

Also: When there are conflicts of interest in consulting

2. The medium sets the bar

The nature of the medium sets all the standards, journalistic integrity be damned! Since time is money, the impulse to check facts is damped or in many cases completely absent.

Blogging demands newness. Nothing new, then it must be invented. Take the presidential election campaigns & nobody candidates as prime example.

Also: When you have to take the fall

3. The economics of blogging is horrible

Search engines and readers alike reward newness with their attention. This puts a constant pressure on bloggers to publish even if it’s crap.

”In a pay-per-pageview model, every post is a conflict of interest.” -Ryan Holiday

He quotes Henry Blodget’s formula that writers need to generate 3x their salary in pageview generating ads to break even. Apparently that comes to 1.8m pageviews per month. Wow!

All this drives up the frequency of posts. It also pushes the average length of a post online down to 335 words. Not exactly a medium for thorough analysis.

Read this: Are SQL Databases Dead?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Are SQL Databases Dead?

mesa verde city

I like the image of this city of Mesa Verde. It’s fascinating to see how ancient cities were built, especially as an inhabitant of one of the worlds largest cities today, New York.

I’m a long time relational database guy. I worked at scores of dot-coms in the 90’s as an old-guard Oracle DBA, and pivoted to MySQL into the new century. Would a guy like me who’s seen 20 years of relational database dominance really believe they could be dying?

There’s a lot to be excited about in this new realm of db, and some interesting bigger trends that are pushing things in a new way.

Join 15,100 others and follow Sean Hull on twitter @hullsean.

1. Growing use of ORMs

ORM probably sounds like some strange fossil archeologists just dug up in the ancient city of Mesa Verde. But they’re important. You may know them by their real-life names, Hibernate, Active Record, SQL Alchemy and Cake. There are many others. Object Relational Modelers provide a middleware between developers and the SQL of your chosen relational database. They abstract away the nitty gritty, and encapsulate it into a library.

In a way they’re like code generators. Mark Winand talks about them in SQL Performance Explained warning of the “eager fetching” problem. This is DBA speak for specifying all columns (SELECT *) or fetching all rows, when you don’t need them all. It’s inefficient in terms of asking the database to read & cache all that data, but also to send it across the network and then discard it on the webserver side. Like a lazy housekeeper the clutter & dust will grow to overwhelm you.

Martin Fowler is the author of the great book NoSQL Distilled. He tries to walk the fence in his post ORM Hate, trying to balance developers love of ORMs, and the obvious need for scalability. Ted Neward calls ORMs the Vietnam of Computer Science.

Mattias Geniar points out that BAD ORMs are infinitely worse than bad SQL and another on High Scalability by Drewsky The Case Against ORM Frameworks.

If you agree the ORM conversation is still a huge mess, you’ll be excited to know that NoSQL sidesteps it completely. They’re built out of the box to interface more like data structures, than reading rows and columns. So you eliminate the scalability problems they introduce when you go NoSQL. That makes developers happy, and pleases DBAs and techops too. Win!

Read: Why Oracle won’t kill MySQL

2. Widening field of options

NoSQL databases are not simply key value stores, though some like Memcache and Riak do fit that mold.

Mongodb offers configurable consistency & durability & the advantages of document storage, no need for an ORM here. You also have a mix of indexing options, that go a little deeper than other NoSQL solutions. A sort of middle ground solution that offers the best of both worlds.

Cassandra, a powerful db that is clustered out of the box. All nodes are writeable, and there are various ways to handle conflict resolution to suit your needs. Cassandra can grow big, and naturally takes advantage of cloud nodes. It also has a nice feature to naturally age out data, based on settings you control. No more monumental archiving jobs.

Hbase is the database part of Hadoop, based on Google’s seminal Bigtable paper.

Redis is another option with growing popularity. It’s a key-value store, but allowing more complex data in it’s buckets, such as hashes, lists, sets and sorted sets. Developers should be salivating at this one.

Also: 5 Great Things about Markus Winand’s Book SQL Performance Explained

3. Lowering bar

The old world of relational databases treat data as sacrosanct. DBAs are tasked with protecting it’s integrity & consistency. They manage backups to protect against disaster. In this world, every bit of data written is as sacred as any other, whether it’s your bank account balance, or a comment added to a facebook discussion.

But modern non-relational databases introduce the idea of eventually consistent. DBAs and architects would say we are relaxing our durability requirements. What they mean is data can get slightly out of sync and we’re ok with that. We’ll build our web applications to plan for that, or even in the case of Riak expose the levers of durability directly to the developers, allowing them to make some changes instant, while others more lax and lazy.

Check this: Why high availability is so very hard to deliver

4. Cloud demands

Virtualized environments like Amazon EC2, give easy access to legions of servers. Availability zones & regions only widen the deployment options. So deploying a single writeable master, the way traditional relational databases work best, is not natural.

Databases like Cassandra, Mongo & Redis are clustered right out of the box. They grew up in this virtual datacenter environment and feel comfortable there.

Related: Why I wrote the book on Oracle & Open Source

5. Only DBAs understand them

Devs may whine at this statement, and to be fair it’s a generalization. The popularity of ORMs speaks volumes here. Anything to eliminate the dreaded SQL writing. Meanwhile DBAs bemoan the use of ORMs for they represent everything they’re trying to fix.

SQL is hard enough, but the ugly truth is each database vendor has their own implementation, their own optimizations, their own optimal tweaks. Even between database versions, SQL code may not perform consistently.

Identifying slow SQL and tweaking it remains one of the primary tasks of performance tuning, for this reason. It hasn’t changed much in my two decades on the job.

Also: Why bemoaning AWS performance sounds like Linux detractors circa 1999

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Scalable Startups is back – happy holidays!

CC license via barrettward
CC license via barrettward

Join 15,100 others and follow Sean Hull on twitter @hullsean.

After some intermittent outages over the past weeks, we managed to get the site rebuilt on a brand new server. Yes we’re still hosted at a traditional datacenter, 1and1.com to be exact. They were very helpful through the recovery process.

Here are five lessons learned.

1. Keep various types of backups

While the site was down, I was scrambling to consider what I had lost and what would be the fastest way to get the site back online. First there is the content, images and database backup. But wordpress also has an export function, so an additional XML backup of all site content proved invaluable. Further you have the software, the content management system of wordpress itself. Yes you can download a new copy, but what about the plugins, and header modifications to support Google Analytics?

Read: Why Oracle won’t kill MySQL

2. Be patient with the support staff

Eventually you’ll need to get on a call with the support techs. They may try to help, but speak of worse case scenarious, and ask if you have a backup, like you’re really going to need it! Remain calm, and ask for clarification.

In my case, the mirrored root drives looked unsalvageable. Turns out that although the md volumes – Linux’s software RAID – could not be rebuilt, the good drive contained most of the data I needed to restore. In that case a filesystem check fixed the journals and brought back a copy of data.

Related: Why Affordable Care Act desperately needs Techops

3. Keep detailed notes of all your components

When you’re scrambling, and frustrated, notes save you. There are way more moving parts than you can keep all in your head, so why not keep good notes too?

For my site, there is wordpress, the version, MySQL and it’s version, config files for Apache & MySQL, dump files of individual schemas, existing installed plugins, themes, mods, google analytics configuration, passwords for the server, and wordpress itself. And don’t forget the logins to your hosting dashboard, PINs and secret identifiers. Write it all down!

Also: 5 Great Things about Markus Winand’s Book SQL Performance Explained

4. Monitor and test more

As it turns out I wasn’t hacked this time around, but was having a disk failure. This was manifesting in a strange way. Software RAID needs to be monitored, as does the syslog & mysql & apache logs.

Also, always be testing. I found that although I was using pingdom to notify me of outages, it would not *repeat* that notification. Since I had an extended outage of many days off and on, I had no idea of this. Pingdom had sent me one notification which I missed, and none to follow.

Check this: Why high availability is so very hard to deliver

5. Don’t forget the holidays!

Yes an outage is serious, but keep a sense of perspective. Have a splash page sitting at the ready, while you’re fiddling with all the components.

Although your digital billboard is down, your audience and customers are probably more patient than you realize. If you provide valued content, they’ll be back!

Read: How to do an architecture assessment for a merger

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Why weekly billing amps up time pressure

http://www.flickr.com/photos/estabrook/5729555412/

Join 11,500 others and follow Sean Hull on twitter @hullsean.

This past year I worked on an 8 week contract. I was tasked with helping improve scalability, measuring current throughput, then troubleshooting systems & infrastructure to find the big problem areas.

Slow process of on-boarding

In only six months, the firm had grown from a small startup, to a larger mid-sized company. That kind of growth is great for margins & investors, but it’s tough on teams & management.

We had outlined a nice todo list up front. Tasks would fit well within our eight week budget, with some additional time for things that came up along the way.

As it turned out, on-boarding for the project got drawn out. I got tangled in email problems, configuring, forwarding, and so forth. The default on-boarding process placed me on various general lists about office parties, and treasure hunts. Having all this email forwarded to me became a problem to untangle.

Meanwhile getting credentials and logins to the correct servers was a challenge. Tickets were created, emails flew back and forth and time rolled on.

Read this: Why operations & MySQL DBA talent is hard to find

Time pressure at the end of engagement

As the engagement barreled on, we reached the final two weeks mark. It was then that I scheduled another meeting with the director of operations, and to go over status.

At that point the team was fighting some new fires with database change management. I was intrigued by the problem, and wanted to dig in and see if I could assist. But at that point we both agreed there wasn’t sufficient time left to devote to it.

Having spent a large portion of the engagement up front on administrative tasks, we now had time pressure at the end to finish the tasks agreed to.

Related: 8 Questions to ask an AWS expert

The hourly billing experience

I’d worked on many hourly clients over the past decade. With hourly projects the VPN configuration, logins & admin tasks sometimes fell through the cracks. Firms of all sizes, even small startups, often have a lot of balls in the air at once.

On hourly billing, when things get drawn out, there’s no real pressure. The cost to the firm is the same whether they drag their feet or push to get things done rapidly.

Read this: Why Amazon RDS doesn’t support Maria DB or Percona

Contrast with weekly billing – mutual accountabilities

The contrast with weekly billing engagements is palpable. You feel it right out of the gates. We both want to make good use of time. And clients feel they don’t want to waste resources, and budgets.

That’s a good thing. There’s an incentive on everybody’s part to keep things moving.

Also: Why generalists are better at scaling the web

We act when we feel it in our wallet

My conclusion from these experiences, we act when we feel pressure on our wallet. With weekly billing the client will pressure their own teams on mutual accountabilities. They’ll also pressure you the consultant or service provider. So be prepared to pull your own weight.

When things are not moving along smoothly, expect discussion to quickly bubble to the surface. Embrace these moments, for everyone will have incentive to solve those problems.

Time pressure & budgets – keys to successful consulting engagement.

Related: Why I don’t work with recruiters

Get more in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample