AppFog Blog

Weekly Roundup: The Week in Pictures

NodePDX Logo

This past weekend, the first ever NodePDX conference took place in our hometown of Portland, Oregon. AppFog was a proud sponsor of #nodepdx, providing the attendees with the official conference tee and AppFog tees.

Photo of an AppFog t-shirt

photo courtesy of @lhawthorn

(Speaking of AppFog swag, our Community Manager has been busy sending out tees this week to folks who build cool stuff on PHP Fog or write up awesome tutorials about how to use the service. Let her know what you’re building or writing and swag may be thine!)

Our partner, New Relic, sponsored the conference after party and brought along some swag of their own, modeled by event space sponsor NedSpace’s own triceratops.

Photo of New Relic t-shirts

photo courtesy of @adron

And the fine folks from Cloud Foundry brought along their own swag magic.

Photo of Cloud Foundry stickers, USB sticks

photo courtesy of @dukeleto

In addition to cool tees, AppFog also let the conference organizers borrow our projector – gotta love actually seeing the slides – and ‘brought the chillax,’ namely free massage for all speakers and subsidized massage for all conference attendees. Several NodePDXers also competed in the lunch time talent show to get free massages!

Our favorite part of the conference? All the awesome stuff you can do with Node.js.

All the talks were livestreamed, and you check out videos of all the conference sessions.

Many thanks to Troy Howard and Adron Hall for organizing NodePDX!

Fast forward to Wednesday and the Cloud Mafia Meetup in San Francisco, California. Dubbed “See Inside the Cloud: Deploying, Monitoring and Managing Your Apps,” the meetup featured speakers from New Relic, Loggly and our very own Chris Tacy on “Lessons Learned: Developing Apps for Virtualized Resources.”

photo of Chris Tacy

photo courtesy of @newrelic

Even when in SF, Chris rocks the Stumptown love.

Chris was joined by our guest, the dapper Casey Bisson from GigaOM, who talked about their decision to migrate GigaOM Pro from a dedicated hosting environment to the cloud.

photo of Casey Bisson

photo courtesy of @newrelic

And since we’re talking about events, AppFog is a proud sponsor of WordCamp Phoenix. We have two free passes to the event to give away, first come, first served. Talk to Leslie Hawthorn, our Community Manager, if you’re interested.

Last but not least, and while it’s not strictly ‘pictures,’ we’ve had some awesome posts and news of PHP Fog and AppFog from far and wide:

And that’s a wrap. Happy hacking this weekend!

AppFog: Entrepreneur Enabler

From the desk of AppFog’s Director of Marketing, Chris Tacy….

I think everyone understands that PaaS solutions like PHP Fog and AppFog (and, for that matter, all core cloud technologies) are enabling technologies. I do not, however, think that most folks understand exactly what is being enabled. I think people tend to have a very narrow view – and consider that the only thing being enabled is more tech.

While it is true that AppFog does enable other forms of technology (apps in our case), I feel that the bigger picture is that core cloud tech like AppFog also enables start ups.

Over the last year or so, there has been a lot of talk about the Entrepreneurship Boom. More and more start ups are being created – and at an increasing velocity. People have, rightly, identified the decreased barrier to entry for starting such a company as a major driver for this change, and the employment market in the US as a secondary driver. What has been largely ignored in this conversation, however, is the role that core Cloud technologies have played in creating this decreased barrier to entry.

While some folks have, in fact, identified core Cloud tech as a driver, this has largely been lost in the froth and link-bait and sensationalism. For every Chris Sacca that sees the underlying changes driving this Boom (“The biggest line item in these companies now is rent and food…  A decade ago, I don’t think you could write a line of code for less than $1 million.”) there are a thousand Pei-Wing Tams and Jason Calcanises.

I’m hoping that this piece will cut through the Boom vs. Bubble distractions to uncover what is really going on, what has created this Boom, and why it’s causing the changes we are seeing.

To provide a little context, I will walk you through a little bit of the history of the Cloud – from a perspective of how the changes have impacted start ups.

In the 90s, we saw the introduction of managed datacenters, providing hosting and connectivity related services. The shift to managed datacenters created exponential savings in both cost and time for internet technology based start ups. This accelerated the start of a boom in early stage investing due to the decreased risk profile that was created. Many of the largest dot-com wins were fueled by this dynamic.

As we entered the 21st century, the introduction of virtualization created another round of exponential cost and risk reduction. By de-coupling physical hardware from the resources represented, start ups were able to not only decrease upfront costs, but were able to scale in a more agile manner.

In 2006 these exponential savings passed a tipping point in the early stage start up environment.  With the launch of Amazon Web Services (AWS) we saw the development of APIs built on top of this virtualization layer.

By using AWS, developers were able to more completely abstract the IT / resources aspects of creating software. The exponential savings in time and cost (as compared to working directly with virtualized resources) from using these APIs is one of the largest drivers for the recent boom in the internet tech market.

As compared to even the risk profile of doing a start up in the 90s using managed datacenters, doing a start up was suddenly dramatically less difficult and scary.

So, now that we have the historical context – let’s look at the numbers behind this so-called Entrepreneurship Boom.

Looking at combined seed deals (Angels plus VCs) using data from the National Venture Capital Association and the Center for Venture Research we see the above results. When we graph this data, we see something very interesting.

As you can see, deal size and deal volume are coupled until 2006. At that point, they (rather suddenly) become de-coupled. Hmmmm…..

So what happened in 2006? Oh yeah… AWS launched and suddenly developers were able to quickly and easily launch products with dramatically reduced upfront (and CapEx) costs – and were able to adjust product and business direction in a highly responsive and agile manner as a result of this core Cloud tech.

Launching a start up in 2007 was suddenly a ton cheaper, easier and less risky. Planning for success and scaling was moved to a “nice to have” problem that you’d deal with when it became a problem (witness the myriad success-created fails at this time – the Twitter Fail Whale is a great example).

So, AWS decoupled funding size and volume of deals. Why? Because doing a start up was cheaper (resulting in decreased funding size), but also had a decreased risk profile (resulting in increased volume). Increased agility meant we all became far too familiar with the word “Pivot” (decreased risk to investors). First mover advantage largely disappeared with the exception of hyper-growth companies (hard if not impossible to plan for), resulting in tons of “fast follower” clone start ups appearing (and becoming successful). This again decreased investor risk.

“We’ve long argued that what open source did for software in terms of democratizing access and availability, the cloud would do for hardware. When you can get ten nodes and a terabyte of storage for a ten dollar bill, that’s transformative. This research suggests that that conclusion is indeed correct, with the number of deals spiking shortly after the creation of the cloud market.” – Stephen O’Grady, Co-founder RedMonk

And as you can see from the chart… this has continued to accelerate.

Why?

More core Cloud Tech of course.

In 2011, start ups saw another round in exponential savings-creating technologies as products like Chef and Puppet increased their marketshare. By adding a layer on top of APIs that handled SysOps in a more systematized manner, the cost of managing software built in the cloud was again exponentially decreased. In addition, these technologies gave developers the opportunity to shift their time away from doing IT work and towards writing code (what they are supposed to do).

At this time we had, as a result, reached the point where it was realistic to form a start up and launch an internet tech based product (using this full cloud stack) for less money (and in less time) than it would have taken to simply launch the website for such a company in 1997. Hacker News started to promote more and more stories of folks creating a start up from inception to launch in a month. Then in a week.

At this point the discussion of Boom or Bubble started. The volume of start ups was simply too large to ignore.

In my opinion, this is a Boom (not a Bubble). There has been a paradigm shift in the cost and risk associated with doing an internet start up. A Bubble, by it’s nature, is based on fantasy and speculation. A Boom, however, is based on underlying changes to fundamentals. This, then, is a Boom.

Will it continue? All signs point to the answer being yes if we look at the sort of Cloud tech that’s coming in the next year or two.

As we enter into 2012, the cutting edge of Cloud tech lies in App Lifecycle Management. And once again, the savings derived for a start up are exponential in nature. By moving the human costs of setting up and managing Apps on the SysOps layer, velocity is increased exponentially as well – and on-going costs decreased be a commensurate amount.

So where does this all lead? In our opinion the end-game is NoOps. NoOps is where building and running an app is purely a developer process – and where developers are not having to spend (much) time doing Ops work. Where instead of spending ⅓ of their time doing Ops or DevOps work, developers are spending 5% of their time managing Ops-related systems and tools.

This does not mean that there will be no Ops, at all. It’s just that for developers, Ops will mostly be handled through services, systems and products. And it doesn’t mean that there won’t be Ops jobs – just that most start ups won’t need as many Ops people. The big exception, of course, will be in the core Cloud tech space – where companies like VMware, PuppetLabs, MongoLab and AppFog will be the primary employers of Ops folks.

NoOps is the future. But it’s a very near future. What we’re doing here at AppFog is, in fact, building this future. We are committed to taking all of the exponential gains from each layer of this Cloud 2.0 pyramid and passing them along to developers and entrepreneurs as one, rolled-up, massive reduction in cost, time and risk.

By freeing developers to focus on what they want to do – and on what they do best – we are enabling them to even more easily start companies and build products. And that is why we are start up Enablers.

To provide a personal example, my first start up was founded in the early 90s. We raised millions of dollars in seed funding and spent a year building and launching a proof-of-concept. Our hardware budget for this proof-of-concept alone was almost $500k. Our IT staff when we launched the proof-of-concept (in Alpha) was ¾ the size of our dev team. And that was the standard.

If I were to recreate that start up today, using these core Cloud technologies and following a NoOps approach, it would take probably 2 months to get to proof-of-concept (with the same dev team), would require no IT staff, would require $0 in hardware budget, and would cost a couple hundred dollars a month for Cloud services to start. Once launched, iteration on the product would be quicker, easier and cheaper by orders of magnitude. Scaling would occur only as needed (so we only would need to pay when we were successful). Total funding required would be roughly 1/10 of what was required at that time.

For your average entrepreneur, this is the difference between “I wish I could do that” and “screw it, let’s just try it.”

And that’s what we live for – making everything a little less scary and a lot easier.

PHP Fog and The Smithsonian

Imagine our delight when we discovered that the Smithsonian Cooper-Hewitt, National Design Museum was running their site on our flagship PaaS product, PHP Fog!

Normally, we’d be treating you to our traditional Friday round up post right about now; instead, we’d like to share one of our customer’s success stories. Plenty of our team members have fond memories of visiting the Smithsonian’s many museums, our impressionable and nerdy brains feasting on delights from the Apollo 11 Command Module to the Hope Diamond.

Read on for more from Micah Walter, Cooper-Hewitt’s webmaster and PHP Fog afficianado…

Moving to the Fog

When people have asked me where we host our website, I have usually replied with “it’s complicated.”

Last week we made some serious changes to our web infrastructure. Up until now we have been running most of our web properties on servers we have managed ourselves at Rackspace. These have included dedicated physical servers as well as a few cloud based instances. We also have a couple of instances running on Amazon EC2, as well as a few properties running at the Smithsonian Mothership in Washington DC.

For a long time, I had been looking for a more seamless and easier to manage solution. This was partially achieved when I moved the main site from our old dedicated server to a cloud-based set of instances behind a Rackspace load balancer. It seemed to perform pretty well, but still I was mostly responsible for it on my own.

PHP Fog Graphic

PHPFog can be used to easily scale your web-app by adding multiple app servers

Eventually I discovered a service built on top of Amazon EC2 known as PHP Fog. This Platform as a Service (PaaS) is designed to allow people like myself to easily develop and deploy PHP based web apps in the Cloud. Essentially, what PHPFog does is set up an EC2 instance, configured and optimized by their own design. This is placed behind their own set of load balancers, Varnish Cache servers and other goodies, and connected up with an Amazon RDS MySQL server. They also give you a hosted Git repository, and in fact, Git becomes your only connection to the file system. At first this seemed very un-orthrodox. No SSH, no FTP, nothing… just Git and PHPMyAdmin to deal with the database. However, I spent a good deal of time experimenting with PHPFog and after a while I found the workflow to be really simple and easy to manage. Deployment is as easy as doing a Git Push, and the whole thing worked in a similar fashion to Heroku.com, the popular Ruby on Rails PaaS.

What’s more is that PHPFog, being built on EC2 was fairly extensible. If I wanted to, I could easily add an ElastiCache server, or my own dedicated RDS server. Basically, through setting up security groups which allow communication to PHPFog’s instances, I am able to connect to just about anything that Amazon AWS has to offer.

I continued to experiment with PHPFog and found some additional highlights. Each paid account comes with a free NewRelic monitoring account. NewRelic is really great as it offers a much more comprehensive monitoring system than many of the typical server alerting and monitoring apps available today. You can really get a nice picture of where the different bottlenecks are happening on your app, and what the real “end user” experience is like. In short, NewRelic was the icing on the cake.

New Relic Dashboard Image

Our New Relic Dashboard

So, last week, we made the switch and are now running our main  cooperhewitt.org site on “The Fog.” We have also been running this blog on the same instance. In fact, if you are really interested, you can check out our NewRelic stats for the last three hours in the “Performance menu tab!” It took a little tweaking to get our NewRelic alerts properly configured, but they seem to be working pretty seamlessly now.

Ed. Note: This post was originally published on the Cooper-Hewitt Labs Blog and is reproduced here with permission. Many thanks to Micah and our friends at Cooper-Hewitt for sharing their story with us.

Getting Lean and Solving Problems: Farewell to Git Submodules

Sometimes, you have to let a good thing go. This time around, we’re letting go of something that encourages what we feel is sub-optimal application development. And the great news is that only 0.3% of all applications deployed on PHP Fog use this feature. As of Friday, February 17th, we’ll be deprecating support for git submodules in deployed apps on PHP Fog. This means that PHP Fog will no longer sync or update git submodules when deploying applications.

So why are we making this choice? Syncing Git submodules has caused us a number of issues with reliably deploying your applications. Submodules can point to Git repositories that have gone away or are otherwise unavailable, they can overwrite files that have been written to disk by your web app, and developers have accidentally pulled in unwanted changes from submodules that have broken their app in production. Each of these issues can be extremely difficult to fix.

We’re here to help you deploy your apps with velocity and grace, so rather than spending engineering resources to support a feature that so few of our customers use – and that causes an inordinate number of headaches – we’re continuing to make PHP Fog leaner and better. And we’ll have two cool new features to tell you about next week that should make your life a whole lot easier.

Are you using Git submodules on PHP Fog? No worries… we have your solution.

We have evaluated several PHP package and dependency management tools and have decided to recommend Composer. Composer will allow you to specify a manifest of “packages” from a main package repository “Packagist” and Git repositories. Composer will manage putting them into your source folder without needing to use Git submodules. You then check these dependencies into your application’s Git repository like normal files, with none of the problems associated with Git submodules. It also gives you finer-grained controls over which versions of your dependencies you wish to use and provides better parity between your development and production environments.

Need help making the transition? You got it! We’ve created a walk-through for replacing a Git submodule dependency with Composer on our help site, and you can check out the code for this example application that has several dependencies and is constructed according to our best practices model. If you need additional help, you can get request assistance from our awesome support engineering team.

More questions? Comments, concerns, feedback? We always love to hear from our customers about what they need from us. What should we add? Anything you never use that you’d like to see hit the cutting room floor? How do we make PHP Fog your dream PaaS? Talk to us! @appfog or Facebook or Google Plus.

Blitz.io and Iron.io Now Available as Add-Ons for PHP Fog

We’re thrilled to let folks know that we’re continuing to grow our add-on program. We’ve added two new partners this week: Blitz.io and Iron.io. We’re very excited about adding these new tools in the arsenal so you can focus on the business of writing excellent applications with velocity and grace, free from worry about your IT infrastructure. Blitz.io and Iron.io join our existing partners, MailGun, MongoHQ, MongoLab and New Relic. If you are developing and managing applications using our flagship PaaS product, PHP Fog, you absolutely need to check out these new add-ons.

A Bit More About the Add-on Program

The AppFog Add-On program, introduced in December, allows users of PHP Fog to develop apps that integrate functionality from these third party partners easily and to manage accounts with their services from a single interface. This intuitive interface displays partners’ services options, allowing the customer to easily integrate additional functionality into the applications they build on PHP Fog and soon AppFog as well. We will continue to expand its partner ecosystem adding new tools and solutions to the program throughout the year.

From Our New Partners

Here’s a bit more from the fine folks at MuDynamics, creators of Blitz.io, and from Iron.io about why they’re excited to be part of the PHP Fog platform and the AppFog family…

“We’re very excited about making Blitz an AppFog ‘Add-On’. This program is an outstanding way for developers to quickly access the best development solutions available from within AppFog. The integration of Blitz is another piece in this puzzle, enabling developers to quickly create rock solid applications without having to learn the nuances of load and performance testing.” – Ajit Sancheti, Co-Founder, Mu Dynamics

Blitz provides load and performance testing as a service. Using Blitz with PHP Fog, developers can quickly perform this testing without ever leaving their PaaS console.

“Cloud developers need fast deployment along with the ability to scale. When it comes to message handling and background processing, most developers spend a lot of time creating and managing these components. IronMQ and IronWorker offload the challenges of maintaining what ends up being pretty complex systems into massively scalable services. Like AppFog, Iron.io is committed to removing complexity for developers, and we are excited to work together on this mission. Through our partnership, developers can spend far less time managing infrastructure and far more time on areas of their application that really matter.” – Chad Arimura, CEO and Co-Founder, Iron.io

Iron.io provides message and task queues as a service. This allows developers to integrate enterprise class queuing without having to mess about with complicated integrations and expensive products.

What Are You Building?

We’re excited to be adding more partners to our ecosystem, but we’re much more interested in how these partnerships enable your success. What cool stuff are you building? How has the Add-On program made your life easier? Your application better? Your users more delighted? Our Community Manager, Leslie Hawthorn, would love to hear from you.

NodePDX: The Tech Conference Not to Miss

Editor’s Note: This week we’re pleased to welcome guest blogger Troy Howard. Among his many accomplishments, Troy is an Apache Lucene committer, the bassist for Lubec andthe organizer of the upcoming NodePDX Conference. Troy was kind enough to give us a preview of the conference and his thoughts on Node, Portland geekery and more.

Some Reflection On Node.js

Node.js is a strange beast. It’s a technology that might just be worth the hype surrounding it. In this day an age, when everyone expects ‘viral’ to be part of their marketing campaign, when something actually does become popular rapidly and ends up with a bunch of people talking about it, it’s easy to discount the validity of the hype. Especially when it’s something as unexpected as serious developers being outspoken about how amazing Javascript is.

It’s almost like you’re living inside of a bad joke… But I gotta tell you all, this is no joke. Node.js really is all that and it doesn’t matter what the business folks say, what the marketing folks say or what the jaded developer to your left snidely derides. This is serious technology and it’s relevant.

Why Portland?

So you all have seen Portlandia, right? Well, it’s true. We here in Portland are a bit off our rockers and we’re passionate about a lot of things. We’re living proof that even though idealism may not apply globally, it can certainly live in a bubble and work here. As you might expect, we have a very idealistic software development community here. This is the land of fancy beer drinking beardos who crank out wicked bleeding-edge open source code on their sticker-encrusted macbooks and who look at you like you’re speaking a foreign language when you talk about LOB apps, COM+, or “enterprise solutions”. It’s only natural that Portland would become a center for innovation and adoption of emergent technologies. We may not have the vibrant start-up culture of SF or NYC ( or do we ? )
but I guarantee you we care about technology more than your average bear.

NodePDX == Node.js + Portland

Portland was a natural environment for hosting the two main conferences of 2011 for Javascript and Node.js. Apparently the weather scared them away. While NodeConf will be returning this summer, NodeSummit took place in sunny business-friendly San Francisco and JSConf has chosen the dusty and dry environs of Scottsdale, Arizona this year (yep, PDX has 384% the rainfall, and we -deal with- love it!).

Well, we still admire Javascript here in Portland. Business interest or no business interest, we want to share, talk and hack together as a community indulging in our excitement for what has already been called the “Technology of The Year” for 2012 (who decides these things anyway?).

That’s what NodePDX is all about. This is a grassroots, independent, non-commercial conference. That means that everything is donated. Everything, including the event venue (thanks NedSpace), the screen, the microphone (thanks PIE), the projector, the t-shirts, the on-site massage therapist (thanks AppFog), the logo (thanks Julie), and even the hosted open-bar after party (thanks New Relic)… oh, and all the speakers, and the volunteers, who are doing this out of their passion for legit technology, without even thinking about money (not that we have anything against money. We love money. It allows us to buy beer, laptops and food… Without those things we couldn’t hack on JS all day and night, duh).

So, put on your thinking cap (and if you’re not from here, grab your umbrella) and come join us for a couple days of raw geekery. I guarantee you’ll learn something and have a good time doing it.

Several members of the AppFog engineering team will be attending NodePDX and enjoying the talks, hallway track and on-site massage. Hope to see you there!

Weekly Roundup: NoOps, #FreetheDevs and Un-tether from Your Laptop

Jumpstarts

As usual, we’ve been hard at work here at AppFog HQ adding new functionality to our flagship PaaS product for PHP, PHP Fog. We’re huge fans of Twitter, in case you hadn’t noticed, so we’re thrilled to have added a Jumpstart for Bootstrap today. Thanks to Twitter for open sourcing this amazing tool! Head on over to Github for all the code and documentation you’ll need to know Bootstrap and make it jump on PHP Fog.

We’ve also added a Jumpstart for the Yii Framework, a high performance PHP framework targeted at building fast, secure Web 2.0 applications. We’ve also recently upgraded several of our jumpstarts to the lastest version of the code base, including CakePHP, CodeIgniter, Elefant CMS, Joomla!, Laravel, MediaWiki, PyroCMS, Slim, SugarCRM, WordPress and Zend.

So why is having the latest and greatest available as a Jumpstart in PHP Fog so cool? It’s not just getting all the new features, bug fixes and security updates. It’s having the opportunity to do rapid prototyping using bleeding edge code as the foundation for your big ideas. It’s a chance to use the latest features with maximum utility and to know that going down that rabbit hole isn’t going to cost you very much in the long run. Sometimes the rabbit hole goes someplace wonderful, sometimes it doesn’t. We’ve got your back!

So where has PHP Fog taken you? Our Community Manager, Leslie Hawthorn, is starting a project to collect cool customer stories. Talk to her about what you’ve built – we even have some attractive, low-fat, high fiber t-shirts to give away to the brave travelers of the fog.

*Ops: Where Do You Sit?

You know you’re onto something when one little infographic starts one hell of a Twitter storm.

Or perhaps you followed the debate on LinkedIn: So whether you think we let our marketing team out the door with a design budget and no Stumptown or you’re delighted by the idea of ditching systems administration tasks in favor of code, code and more code, we’re excited to hear what you think.

Where do you weigh in here – AppOps? DevOps? NoOps? Skynet?

AppFog for Your iPhone

We’re all about allowing developers to deploy applications with velocity and grace. What could be more graceful than easily managing your AppFog and Cloud Foundry instances on the go, directly from your iPhone? AppFog’s iOS app is now available in the App Store.

From the Stuff You Probably Already Knew Department

AppFog, our language agnostic PaaS, is still in private beta. You can sign up for an invite at http://appfog.com.

And that’s a wrap – see you next week!

Actually… Yes, there IS an App for that!

You are sitting at the airport, waiting for your flight when suddenly a Hacker News story about your wicked cool new product hits. As usage of the product skyrockets, normally you’d be desperately trying to start your laptop and find a WiFi hotspot and connect to the internet… all while watching your product slow… then fail. A nightmare.

Well, assuming you’re running your product on AppFog – now you can manage and run your apps through your iPhone!

With our new iOS app, you just pull out your iPhone and scale the application – all while standing in line to board your flight. No muss. No fuss. No more fear of being HN’ed to death.

Version 1.0 supports AppFog.com and CloudFoundry.com out of the box. You can use it to connect to any Cloud Foundry instance. You can manage apps, services and instances.

Best thing about it? It’s created by AppFog – and it’s Free.

So what are you waiting for?

Go get it and stop being tethered to your laptop!

What is NoOps anyhow?

Since having our infographic published on GigaOm, there has been a lot of controversy and FUD around “NoOps”. Paul Graham recently wrote about schlep blindness. NoOps is a response to the schlep blindness of developers doing SysOps.

What does NoOps mean:

  • NoOps means developers can code and let a service deploy, manage and scale their code
  • NoOps means automated systems like CloudFoundry managing app lifecycles, not SAs
  • “the point isn’t that ops are going away, but they’re going away for developers” – Derrick Harris at GigaOm

What does NoOps NOT mean:

  • NoOps doesn’t mean that operations are dead and nobody will do them (like this tweet thinks)
  • NoOps isn’t a job role (like this tweet and this tweet thinks)
  • NoOps isn’t blissful ignorance (like this tweet thinks)
  • NoOps isn’t marketing fluff made up by non-technical idiots (like this tweet and this tweet thinks)

This is the true spirit of NoOps:

“Netflix runs NoOps … Netflix is a much larger example of a PaaS based NoNops organization … We  claim a competitive advantage from the agility and automation of a PaaS based product and a NoOps organization.” - Adrian Cockcroft, Cloud Architect at Netflix (read more)

And this:

malminhas
From DevOps to NoOps via PaaS. Am +1 for devs doing more dev and less ops

Short history of SysOps

The growth of the SysOps movement has been driven mainly by developers who were tired of two things:

  1. Developers tired of waiting for systems administrators because they did their work inefficiently
  2. Developers tired of doing the work of systems administrators inefficiently

Why is it so hard to hire SysOps roles?

Because most SA’s aren’t versed in the programming needed to manage SysOps and because most developers who can use SysOps tools don’t want to spend their time doing SA.

Since SysOps roles are so hard to fill,  what usually happens is all the developers at a company become responsible for handling ops through the SysOps tools (read SiliconANGLE to hear a contrary opinion to why schlep should stay).

SysOps is adding more horses to the carriage. NoOps is the car.

I understand why legendary ops guys like John Allspaw (Flickr, Friendster, Etsy) are scared of a term like NoOps and resort to calling it names.

allspaw
“NoOps” beats “cloud”, “agile”, and “SOPA” as the dumbest marketing term ever coined in my field. http://t.co/53On2fZf #devops



NoOps is not for ops guys. It’s for developers. More dev and less ops.

It is not a job title because with NoOps, you don’t grow by adding headcount to your ops team. You grow by moving sliders. You grow by connecting managed services together. You grow by focusing on your core competency: coding.

Doesn’t this mean ops are dead?

No. SysOps is blueray, NoOps is streaming. Blueray is going to be around for a long time and there is a strong market for it. There will be people wanting to play blueray disks for decades to come. But streaming is a generational shift.

SAs and DevOps guys are always going to have a place to work. As long as there are datacenters, you will always be able to get a job at AWS, Google, TerreMark, etc. etc. As long as there are legacy systems, SAs and DevOps will be employable positions. That is not going away any time soon.

NoOps is for developers to focus on core competency

Ops isn’t a core competency or differentiating factor for many high tech startups. Ops is a necessary schlep for most high tech startups.

Customers don’t choose between groupon and livingsocial based on how well they hook their nginx confs together. Assuming NoOps services like AppFog and Heroku did just as good a job if not better than an in-house ops team, NoOps enables you to build and run high tech startups and enterprises without investing as much in the ops side.

Conclusion

Ops guys despise the term NoOps and will try to drag it through the mud. There is no need. NoOps is not the antithesis of ops. NoOps is simply recognizing inefficiencies for developers and optimizes around it.

NoOps is happening whether people want it to or not. Developers are driving it. They are driving it at startups, they are driving it at SMBs, they are driving it in enterprises. All NoOps does is give this shift a name.

Come Take A Closer Look at PHP Fog

Have questions about AppFog’s flagship PaaS product for PHP applications? Wonder no more. Our CEO and Founder, Lucas Carlson, will be hosting a webinar tomorrow providing an overview of PHP Fog. Lucas will provide a deeper dive on the platform as a whole, including a live demo showing how to deploy and scale an app. By the time Lucas wraps up Q&A, you’ll be ready to use PHP Fog to deploy your applications with velocity and grace.

When: Thursday, February 2nd at 11 AM Pacific Time – convert time zone
Registration: Sign up now

If you aren’t able to make tomorrow’s webinar, no worries. We’ll also archive the presentation, so stay tuned to this space in the coming days if you can’t join us live. We also plan to host future webinars on a variety of topics, so do us a favor and let us know what you’d like to see us cover next time.

Powered by Olark