Category Archives: All

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

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

5 startup & scalability blogs I never miss – week 2

5 blogs week 2

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

Hunter Walk – Startups

If you want to have your finger on the pulse of startup land, there aren’t many better places to start than Hunter Walk’s 99% humble writings. Google finds his top posts on topics like AngelList, Advisors, and reinventing the movie theatre. Good writing, insiders view.

Read: NYC technology startups are hiring

Arnold Waldstein – Marketing

I first found Arnold’s blog using my trusty disqus discovery hack. He had written an interesting piece about new mobile shopping at popup stores like Kate Spade.

Follow him on Disqus, follow the blog, get the newsletter. All good stuff.

Read This: Why hiring is a numbers game

Claire Diaz Ortiz – Social Media

Claire writes a lot about social media, twitter & blogging. She wrote an excellent guide to increasing your pagerank, another on 30 important people to follow on twitter and more. She can even help you find a job.

Check out: Top MySQL DBA Interview questions for candidates, managers & recruiters

Bruce Schneier – Security

Bruce Schneier is one of the original bad boys of computer security. He writes about broad topics, that affect us all everyday from common sense about airport security, to the impacts of cryptography for you and me. Very worth looking at regularly, just to see what he’s paying attention to.

Also: Why operations & MySQL DBA talent is hard to find

Eric Hammond – Amazon Cloud

Eric Hammond has been writing about Amazon Web Services, EC2 & Ubuntu for years now. He maintains and releases some excellent AMIs, those are the machine images for spinning up new servers in Amazon’s cloud.

Even if you’re not big on the command line, you can get a lot of critical insight about the Amazon cloud by keeping up with his blog. Jeff Barr’s AWS blog is also good, but not nearly as critical and boots on the ground as Eric’s.

Also: 8 Questions to ask an AWS expert

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

Why I don't work with recruiters, but I learn from them

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

Bring me clients, please… pretty please!

When you first start out as a freelancer, your network is small. Without a steady stream of projects, the tendency is to reach for whatever you can find. Head shops & agencies build a brand, and ongoing relationships with firms. However a project with a middleman is a relationship with him or her, not the client directly. You lose control of a few very key things, such as fees, testimonials and payment terms.

Read: NYC technology startups are hiring

It’s all about the relationship, Luke

With independent consulting, your relationship with clients is key. Fostering that relationship, builds trust, communication, and confidence in you as a service provider. Doing operations and database management, a CTO, VP or Director of engineering needs to be confident entrusting enterprise systems to you. Security of assets, reliability that things won’t break, and consistency are all crucial.

Working with a recruiter, agent or head shop the client then may feel a stronger relationship with that firm. Testimonials and due credit for successful completion of a project may go to them rather than to you directly.

It also means you lose control of the conversation about fees. Want to do project or week-based fees, your suggestion may fall on deaf ears. What’s more you will share large margins that could amount to 25% or even 50% of the overall fee.

Read This: Why hiring is a numbers game

Headhunters have the pulse of the market

With all those complaints, you might think I don’t like recruiters much, but you’d be sadly mistaken. It turns out I learn a ton from recruiters, and almost always take their calls.

o those conversations are good practice for talking shop
o they provide good feedback & ask questions about confusing areas in conversation
o buzzwords will pop up prominently, helping you understand what their clients needs are
o gives you a bit of the pulse of the market

I learn to speak in broad terms, in a language managers and folks at all levels of an organization can understand, and I learn patience too.

Check out: Top MySQL DBA Interview questions for candidates, managers & recruiters

Recruiter pings – a key performance indicator

Over a ten year period you start to notice trends. Certain times of the year I get more calls & more pings from talent agencies. Here’s what I monitor:

o recruiter views of my linkedin profile
o recruiters email me on linkedin
o recruiters call me
o recruiters signup for my newsletter

Also: Why operations & MySQL DBA talent is hard to find

Learn from people whose business is communication

Although I don’t have referrals or connections for the HR or search consultant that’s reaching out to me there is still lots I can learn. At the end of the day, recruiters are in the business of relationships, and that’s where I become the humble student.

Also: 8 Questions to ask an AWS expert

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

5 Superb blogs this week

Why wait for the new year to start something new? I come across a lot of great new blogs, while digging through the interwebs. So I thought I’d start a regular column to feature the best ones. We’ll including gems from web 2.0 industry, startups, business & management, and of course some technical devops & cloud computing ones.

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

1. Todd Hoff’s High Scalability

Todd Hoff’s High Scalability has been around for years, and offers up a cup of espresso for your infrastructure daily. From important topics like why you should avoid ORMs (Object Relational Modelers see post on technical debt) to regular scalability around the web posts to keep you on track.

He also features great articles under the title “real life architectures” from heavyweights such as facebook, twitter & youtube. These are the gold nuggets that are indispensable to devops and startups.

Read This: 5 Reasons Devops Should Blog

2. Albert Wenger’s Continuations

I was tipped off to Continuations using the Disqus commenting system’s discovery features. Click through to the community tab on say Fred Wilson’s AVC blog and you can find top commenters and where they blog at.

Wenger’s posts include such gems as Anatomy of a URL, giving a lay audience a little insight into the ubiquitous web paths and Computing Building Blocks which dissects the internet stack for everyone. As a partner at Union Square Ventures he’s obviously looped in with the big boys, but his writing style is so great he offers a model for technical bloggers everywhere.

Check out: A CTO Must Never Do This

3. Andrew Chen

Let’s face it Andrew Chen is the rock star I want to be! He’s got tons of organic followers on twitter, and reading his blog & newsletter it’s no surprise. He’s bright, and always provides Nate Silver style insights & new perspectives.

What is a minimal homepage, and how will it help me increase signups? Why can’t I seem to find a technical co-founder? What’s a minimum desirable product? You’ll see why Dave MacClure & Mitch Kapor work with him.

Read: AirBNB Didn’t Have to Fail – AWS Outage Postmortem

4. John Paul Aguiar

John’s website may appear a bit busy at first, but that’s just because it is so chock full of useful content. He offers very hands on, down in the trenches advice for bloggers & entrepreneurs. 150k followers on twitter, and articles that get retweeted hundreds of times, means he’s done the A/B testing, and learned to write clearly, and has great insights to share.

One thing he does is a weekly piece on entrepreneurs & users to follow on twitter. That great feature inspired this very post, not least because it offers a steady stream of things to write about, but because I was also featured there recently. I feel like I’ve hit the big time, thanks John!

Related: How to Hire a Developer That Doesn’t Suck

5. Krebs on Security

Brian Krebs is a bad boy. According to Bruce Schneier he apparently pissed someone off so bad, they had illegal substances sent to him through the mail in attempt to frame him.

Clearly his security research and writing is not appreciated by everyone. That said take a look at his website. You’d be shocked to learn what an ATM skimmer is, or what is the value of a hacked PC. Phishing, bots, email spam, gaming & reputation hijacking are just a few of the criminal activities that go on.

Also: The Myth of Five Nines

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

Understand the High Cost of Technical Debt by Ward Cunningham (Video)

A week or two ago, I got into a conversation on Twitter about technical debt, and someone shared this superb video by Ward Cunningham (youtube). Here is Ward’s Interview website.

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

Waterfall, agile, developer or operations, devops, managers, CTOs… everyone should watch this video, for it cuts to the heart of the challenges we face doing modern software development, in a fast paced and always changing environment.

Though it’s not mentioned in the video, I would argue using an ORM is an expensive form of debt, one that is improperly calculated by teams, managers & startups, and one that bites hard into future scalability. Stay tuned for a post about that!

Enough said, here’s the video.

Here’s the transcript of much of the dialog. Appologies for any typos…

1. Metaphors & Thinking

I became interested in the way metaphors influence the way we think

after reading George Lakoff & Mark Johnson’s Metaphors We Live By (Amazon).

An important idea is that we reason by analogy through the metaphors that have entered our language.

Related: 5 Things Toxic to Scalability.

2. Coining Debt Metaphor

I coined the debt metaphor to explain the refactoring we were doing on a product.

This was an early product done in smalltalk. It was important to me that we accumulate the learnings we did about the application by modifying the program to look as if we had known what we were doing all along. And to look as if it had been easy to do in smalltalk.

The explanation I gave to my boss, and this was financial software, was a financial analogy I called the debt metaphor and that said that:

[quote]
If we failed to make our program align with what we then understood to be the proper way to think about our fin objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan. -Ward Cunningham
[/quote]

Also: AirBNB didn’t have to fail when Amazon went down.

3. Need for Speed

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest.

I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Read this: Why generalists are better at scaling the web.

4. Understand the Burden

I think that there were plenty of cases where people would rush things soft out the door & learn things, but never put that learning back into the program. That by analogy was borrowing money thinking you never had to pay it back. of course If you do that you know say with your credit card, evemtually all your income goes to interest & your purchasing power goes to zero.

By the same token if you dev a program for a long period of time, by only adding features, and never reorganizing it to reflect your understanding of those features, then eventually that program does not contain any understanding and all efforts to work on it take longer and longer. In other words the interest is total. You’ll make zero progress.

Check out: How to hire a developer that doesn’t suck.

5. Achieving Agility

a lot of bloggers at least have explained the debt metaphor and confused it i think with the idea that you could write code poorly with the intention of doing a good job later. and thinking that that was the pirmary source of deb.t I’m never in favor of writing code poorly. But I am in favor of writing a code to reflect your current understanding of a problem even if your understanding is partial.

If you want to be able to go into debt that way by dev soft you odn’t completely understand, you’re wise to make that software reflect your understanding as best you can. So that when it does come tiem to refactor it’s clear what your thinking was when you wrote it. and making it easier to refactor it to what your thinking is now.

in other words the whole debt metaphor or lets say the ability to pay back debt, and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.

i think that’s a good methodology it’s at the heart of extreme programming. the debt metaphor is an explanation, one of many explanations as to why extreme programming works.

Read our popular interview guides for candidates, managers & recruiters: MySQL DBAAWS Expert (Amazon Cloud) and Cloud Deployment & Automation Engineer.

Don’t forget, hiring is a numbers game

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

5 Reasons Devops Should Blog

Join 9500 others and follow Sean Hull on twitter @hullsean.

1. Stand up and be heard

Years ago I was sitting on an online forum chatting with an Oracle buddy of mine. This was circa 1998. We were working on an open source tool to interface with Oracle. There were all these libraries, for PHP & Perl, and a lot of developers starting to build tools. We hatched this hair brained idea to write a book about all of this, and pitched it to O’Reilly. They loved it and thus was born the book Oracle & Open Source in 2001.

Writing a book was, is and always will be a lot of work. It was a great learning experience too. Editors critique your writing, and this teaches you to speak to a broader audience, clarify your statements, and including illustrations and stories.

Along with this came opportunities to speak at conferences, user groups and meetups. It’s exhilerating, and professionally challenging, and I enjoyed all of it.

Blogging allows you to do all of the above in a more measured way. Write regularly, get your ideas out there, get feedback, rinse & repeat. What’s more over time you’ll build up a library of material some of which will draw solid, strong, repeat traffic. It may be what you are most passionate about, what ideas you’ve ironed out smoothly, or what material is most missing from the we already. Whatever the reason your analytics will show you the way.

Read this: Database expert interview questions for candidates, recruiters & managers

2. Share your lessons

In professional services engagements, you learn something new everyday. After a few years you’ll have some battle scars & war stories too. For example I used to have a strong distrust of sales. But through real lessons in the feast or famine world of running your own business, you learn some survival instincts. And knowing how to sell your services & expertise is an art all to itself.

Also: A CTO Must Never Do This

[quote]
Getting up and taking a stand isn’t easy. You’ll receive criticism, and likely feel professionally vulnerable at first. But that only makes us stronger engineers, willing to listen, and better communicators.
[/quote]

3. Get opinionated

Taking a stand on controversial topics, is it something you want to do? Is it something you can do confidently, but also being open to criticism, and seeing all sides.

It’s challenging, but in that process it will either open you to new ideas, or make your resolve stronger. And that process is great for your professional development.

Also check out: AirBNB didn’t have to fail – don’t go down with Amazon

4. Withstand a sh*tstorm

Audiences keep you honest. If I were to go out on a limb I’d say technically brilliant, engineering audiences even more so.

I remember a post I did a year ago, which referenced a feature based on a wrong software version. In other words that feature would not work based on my article. The readers tore me to pieces in the comments.

But listen closely now, I’m saying that’s a good thing. Yes criticism is a very good thing indeed. Get enough of it, and you’ll learn to weed out the folks who are just trolls, from the ones with genuine suggestions. And all that makes you stronger!

Learn to listen a bit, and that makes you an even better sysadmin or devop.

Related: 5 conversational ways to evaluate great consultants

5. Learn by doing

Developers, ops, DBAs and Big Data jockeys alike are doers. We sit and code, build & configure components, troubleshoot & tune. Writing is descriptive and often it’s difficult for us to step back and describe what we’re doing.

By writing we carefully sift through our own thought processes to break it down for novices, or a broader audience. This is a learning process for us too. It’s therapeutic. But also it hones our message and makes us better teachers. We literally learn by doing.

Also: The Myth of Five Nines

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

30 Days of Aspirin for your Ailing Management Headaches

Take Two & Call Me In the Morning

I like a book like Gerry Czarnecki’s even if I can’t pronounce his name. He’s laid out things for readers, a very busy bunch who are going to have trouble finding time in their day to read, but can sorely use the advice. Organized into 30 daily bites of probably 15-20 minutes, you can dig through on your commute to work, or on your lunch break.

Also check out Who Moved My Cheese a business self-help classic.

Czarnecki should know. As a 2nd Army Lieutenant then later heading up board of directors at organizations large and small he’s seen a lot. He digs up the best stories, and offers up lessons straight out of his experiences.

[quote]
On interviews – Be careful that you do not let the resume dominate your conversation. You will gain better insight if you listen to what the candidates want to talk about or what they think you want to talk about. – Gerry Czarnecki
[/quote]

Some of the topics you’ll touch on…

o dealing with mistaken hires that don’t work out
o finding a mentor
o career moves & pivots
o setting expectations with new hires
o hitting peak performance
o filling your bus with rock stars

For startups an all-time favorite of mine is REWORK – 37 Signals guys. These guys have taken the lean methodology and built a real business by being efficient. The pages resonate for me as a small business owner. I’ve found many of the same lessons work in the real world for me.

[mytweetlinks]

Also read
Thank you for arguing by Jay Heinrichs
. With some of the best advice on rhetoric, sales, presentations & persuasion, I re-read bits of the book often.

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

3 Things Devops Can Learn from Aviation

I recent went on a flight with a pilot friend & two others. With only 3 passengers, you get up front and center to all the action. Besides getting to chat directly with the pilot, you also see all of the many checks & balances in place. They call it the warrior aviation checklist. It inspired this post on disaster recovery in the datacenter.

Join 8000 others and follow Sean Hull on twitter @hullsean.

1. Have a real plan B

Looking over the document you can see there are procedures for engine failure in flight! That’s right those small planes can have an engine failure and they glide. So for starters the technology is designed for failure. But the technology design is not the end of the story.

When you have procedures and processes in place, and training to deal with failure, you’re expecting and planning for it.

Also check out 5 Conversational Ways to Evaluate Great Consultants.

[quote]
Expect & plan for failure. Use technologies designed to fail gracefully and build software to do so. Then put procedures in place to detect & alert you so you can put those processes into place quickly.
[/quote]

2. Use checklists

Checklists are an important part of good process. We use them for code deploys. We can use them for disaster recovery too. But how to create them?

Firedrills! That’s right, run through the entire process of disaster recovery with your team & document. As you do so, you’ll be creating the master checklist for real disaster recovery. Keep it in a safe place, or better multiple places so you’ll have it when you really need it.

Read this Scalability Tips & Greatest Hits.

3. Trust your instruments

Modern infrastructures include 10′s or 100′s of servers. With cloud instances so simple to spinup, we add new services and servers daily. What to do?

You obviously need to use the machines to monitor the machines. Have a good monitoring system like Nagios, and metrics collection such as New Relic to help you stay ahead of failure.

Setup the right monitoring automation, and then trust the instruments!

Related Real disaster recovery lessons from Sandy.

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

5 conversational ways to evaluate great consultants

Startups and more mature businesses alike, and those large and small, at some point will need to hire a consultant or two. Want to get the best bang for your buck? Ask some tough questions!

Join 8000 others and follow Sean Hull on twitter @hullsean.

1. Make sure they’re not going to quit

I’ve heard so many crash and burn stories over the years, it makes my head spin.

One client had hired a consultant who was supposed to be the best in NYC. After only a few weeks of working with the client, he explained that they were “doing it all wrong”. Furthermore he had a travel schedule to meet, with speaking engagements in South America.

So he basically dropped them! As the client retold this story to me, I wonder if they could hear my head shaking, I was stunned. Who would turn away from a customer in pain? And furthermore turn away from one who could clearly use the expertise of someone who had seen a lot before!?

Keep in mind the reasons why people leave consulting.

2. Be sure they have some war stories to tell

Any consultant who’s been in business for a while, surely has some good war stories to tell. Talk about those, and find out the battles they’ve been in.

I can tell a few myself. In one case I was only 12 hours from leaving for summer vacation when a long time colleague and former client called me. They were in a serious emergency. The big boys, the remote DBAs that many in the industry use, had broken their database. Replication was misconfigured, and they were running blind. I ended up on a SKYPE call fixing the database and troubleshooting problems on Virgin’s inflight wifi. You don’t forget that kind of firefighting.

[quote]
Be sure they won’t quit, ask about war stories, test for some push back and be sure they empathize with your business pain. But more importantly ask them to tell their own business story. You’ll learn a lot.
[/quote]

For another client, back in the dot-com days, their application was stalling completely. Customers were leaving, and so was an 80 million dollar buyout deal. Nothing a few Oracle parameters couldn’t fix!.

And there are always a few tales of woe between sales teams, and the engineers that then must deploy solutions in the real world. Beware the sales wolf in sheeps clothing and do your homework aka due diligence on technical solutions.

3. Ensure they can provide resistance & push back

Good consultants have to walk a tightrope all the time. On the one hand they are tasked with making their clients happy. At the end of the day, improving their position, business bottom line, yes these are crucial. Sure that means saying yes, that means trying to be a problem solver as much as possible.

But always saying yes, avoids hard truths that you have to share. I had one client whose primary Oracle dba went on vacation. Before he left we reviewed systems. Multi-master replication in Oracle is brittle by nature. We both agreed. And I agreed not to change the configurations lest it break other things down the line. Not one week into his vacation a mandate comes back from on high, this change absolutely has to happen now. There are millions of dollars at stake!

Applying strong resistance is necessary to avoid breaking something even bigger. And it was not easy to stand strong in the face of such pressure. But I assured the team that such changes would mean even bigger problems for the company.

4. Find out if they empathize with your pain

In one of the biggest ironic twists, consultants should understand the pain of building a business. Because they themselves have experienced when clients don’t pay so they understand cash flow problems themselves. That is what every small business struggles with, and most startups too!

5. Ask them how they built their business

For me, one of the least appreciated things about independent consulting is, that in the most important ways, it is about running a small business. So someone who has built and kept running a freelance or consulting business knows how to make hard decisions, and keep their eyes on the ball.

A consultant needs to know how to get business first and foremost. But then how to manage engagements carefully. Once you’ve got those two down, keep building your business incrementally.

Someone who has successfully run a real business for years can share the story of what they’ve done. What has worked, what hasn’t worked, how they have pivoted when necessary, how they have failed fast, and moved through it.

They can tell you how they stay cash flow positive, can deliver on time, can be likeable and communicate with teams, and really understand every side of a business.

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

Scalability Tips & Greatest Hits

autoscaling MySQL

Join 8000 others and follow Sean Hull on twitter @hullsean.

In the past two years we’ve written a ton of material on scalability. Here’s the greatest hits…

Why Generalists Are Better at Scaling the Web

The internet stack is a complex infrastructure of interlocking components. An scalability engineer must be adept at Linux, plus webservers, caching servers, search servers, automation services, and relational databases on the backend. We think a generalist with a broad base of experience is most suited to the job of scalability engineer.

5 Things Toxic to Scalability

ORMs should keep you up at night, but so should coupled and locking processes, a single copy of your database, missing metrics and no deployment feature flags.

5 More Things Deadly to Scalability

A followup to the original, we touch on Disk I/O, RAID, queuing in the database (a no-no), full-text searching, insufficient or missing caching and lastly the dreaded technical debt.

Scalability Happiness

A Zen monk might ask what is the sound of one hand clapping? That’s the sound your servers will be making when you apply this one simple principal.

5 Ways to Boost MySQL Scalability

Deploying MySQL as your web-facing database? Here are a few key tips to boost speed & performance.

3 Ways To Boost Cloud Scalability

Building your startup in the Amazon Web Services cloud? There are 3 things you absolutely must do.

Why Your Cloud Is Speeding for a Scalability Cliff

The cloud may seem like the obvious place to build new applications & infrastructure, but there is a precipice hidden from sight…

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