Mike Coyle’s Weblog

Here’s my recommendation for evaluating the Google App Engine: Think of it as the world’s biggest, baddest embedded device, like a smartphone designed by Chuck Norris.

Remember that, just like the folks that build PDA software, you are writing code to be deployed atop a purpose-built, specialized hardware/OS combination that has profound intentional differences from your Mac/XP/Linux desktop environment. And while the hardware/OS vendor (i.e. Google) does everything that they can to bridge that gap, many of these differences cannot be effectively abstracted away.

The teams that will successfully launch apps atop the Google App Engine are the ones that understand and embrace the nature of the platform (both pros and cons), rather than those that grudgingly work around its idiosyncrasies, pining for the Ubuntu-y goodness of their favorite deployment environments.

Folks who treat App Engine simply as an alternate deployment platform for Python-based web applications run the risk of hitting the wall before they get their app out the door. Anything but the simplest applications will likely require some serious RDBMS-to-”Datastore API” architectural transmogrification. And there are still a bunch of Python libraries (Paste, Mako, etc.) that cannot be used in the App Engine environment.

For time spent in the App Engine world will make for an interesting life:

Infinite scalability. Minimal administrative headaches. But no way to run a query with a “GROUP BY” clause.

Plan accordingly.

Google App Engine was announced last night. This is a service that allows you to write a web application in Python and deploy it to Google, where it can run atop Google’s uber-scalable infrastructure. Here is the transcript and video of the announcement, where Kevin Gibbs from Google explains the App Engine’s value proposition (Easy to use, Easy to scale, and Free to get started.)

Like most big announcements, it’s the most sensational aspects of the story that emerge first. But I think that the broader impact of Google App Engine is a fundamental rethinking of the relational database value proposition among the RDBMS’ staunchest allies. Google makes a compelling case for deployment, so long as your application can live within its constraints.

I see data management as the biggest impedence mismatch between the Google App Engine and the traditional web application design. However, over time I’m certain that a set of patterns will emerge to aid the masses in bridging the gap between the relational model and the Datastore API.

They have some great stuff in the Datastore API, and Christian and I are already at work putting together some offerings to help companies attracted to Google’s Infrastructure-as-a-Service model objectively evaluate and/or embrace the App Engine for their web application needs. Email me if you’d like to discuss.

So that being said, I’ll argue the following:

• Is it a giant piece of flypaper to help Google acquire the next generation of startups? Maybe, but I contend that the real killer next-generation apps will need more feature-rich networking capabilities. Let’s wait until we see what kind of XMPP/GoogleTalk integration comes along.
• Is it a sign that commodity web hosting providers are going the way of the corner video store? Perhaps.
• Is it a welcome counterbalance to the Ruby-on-Rails hype machine in the dynamic language arena? Yep.
• Is it a final blow in the in the Google vs. [INSERT NAME HERE] battle for the hearts, minds, and wallets of the IT crowd? No, the Infrastructure-as-a-Service game is just beginning. The Amazon infrastructure offerings are generalized and piecemeal (by design), whereas the Google App Engine is more of a “vertical” play tailored to traditional data-backed web applications.
• Is it a symbolic victory of Django over Pylons in the Python web frameworks world? No, it’s a victory for WSGI. Django just happens to be up on stage, ably and graciously accepting the award on WSGI’s behalf. I think that the stuff coming out of the App Engine ecosystem in the coming weeks will provide additional validation to the idea that WSGI is Python’s not-so-secret weapon.

Lastly, I’ll throw out some predictions, none of which are Earth-shattering:

• An Open Source application stack that emulates the Google App Engine SDK’s runtime environment will emerge from the community for folks that want to build applications that are compatible with the App Engine, but do not want to deploy their application to Google’s cloud at the current time. Also, this stack would provide an option for companies that deploy a custom app to the App Engine, but subsequently wish to take their application in-house.
• Within time, you’ll see integration with other elements of the Google infrastructure (Docs, GTalk, Search, etc.).
• The next language to be supported will be JavaScript, but that will not come for quite some time.

This posting provides some background for our new Python Center of Excellence (PyCOE) consulting offering.

We are slowly entering the post-honeymoon era of Ruby on Rails (RoR). For a while, the IT press was head-over-heels in anointing RoR as the heir apparent to J2EE/.NET development in the Enterprise. Now, there is a much more balanced pro/con view of RoR, especially among the Alpha Geeks.

While the press talks about IT fashion du jour, I think that IT and business folks alike are secretly pining for the next “Visual Basic”, where an easy-to-learn syntax coupled with powerful libraries can be used by normal people to solve real problems quickly in a variety of contexts.

Python fits that bill quite nicely, and is attractive to both hardcore programmers and the “IT is my day job” crowds alike.

Other languages are arguably more [INSERT ADJECTIVE HERE] than Python, but few combine its expressiveness and ease of learning.

Unfortunately for the typical IT manager, it’s hard to figure out what technology horse to bet on, since the popular bets are rarely the good ones. Taking the advice of the high-end IT sages will land you smack-dab in the middle of the pack at best. And following the advice of your sharpest go-to person may yield an approach that doesn’t scale across the talent continuum.

Stop me if you’ve heard this one before: Bob is the smartest guy in the IT department. Bob falls in love with Rails, and makes the pitch to his boss that they should do their new development in Ruby. Bob backs this up with circa-2006/2007 praise that Rails received from…everywhere. They get started and the boss quickly learns three things:

• Bob is happy working in Rails. Woohoo!
• The simple stuff gets done quickly in Rails. Woohoo!
• Everything else carries a pretty steep learning curve for everyone but Bob. D’oh!

Our PyCOE offering provides a contrasting model, one that states that You should not base technology selection solely upon the tastes and preferences of your sharpest employee.

Rather, PyCOE provides a nine-step process for helping companies adopt Python and incorporate the set of tools and approaches that are appropriate to their existing environment, making sure that the tool selection is consistent with the culture, charter, and legacy considerations of the organization, among other factors.

Paradoxically speaking, it’s exciting to help make dynamic language adoption become boring and predictable.

Introduction

As Christian mentioned the other day, we have two new service offerings in 2008, both centered around Python consulting:

• PyCOE.com is our new offering to help organizations build core competencies in Python in a deliberate and predictable fashion in a way that is fundamentally different from the way that firms tried to adopt J2EE and .NET in the past.

  In a nutshell, we help companies create an environment where the easy thing to do is also the right thing to do for their developers, analysts, and QA personnel. We focus on culture, standards, and infrastructure as we help our customers create a Python Center of Excellence (or COE, hence the PyCOE name) in their organization. We do this by approaching Python adoption as business process re-engineering for IT, rather than programmer training.

• PyGuys.com is our new Python consulting brand. We are focusing on small-to-midsize custom development projects, and SDLC process improvement consulting. We’ve been doing Python and Project Management consulting since the company started, but we felt that now was a good time to rebrand and grow our Python consulting business.

We also reworked the Botonomy.com company website, to reflect its role as a “holding company” for our branded service offerings.

Also, just before we launched our new websites, TIOBE declared Python as the programming language of 2007. Not a bad sign, if you ask me.

Here’s an Apple Developer Connection profile of Checkout, a Point-of-Sale application developed in Cocoa and Python, using PyObjC (Python<->Objective-C bridge) to glue the Python-based business logic to the UI and other framework-level Cocoa libraries.

On the value of Python and development process:

Bok explains how this combination contributed to the development efforts. “Using Python and the PyObjC bridge gives you the best of all worlds—Python and Cocoa,” Koen says. “Python is great for unit testing and agile development. Because Checkout manages critical business information, we swear by writing unit tests for everything that even comes close to any financial data.”

Koen continues, “And since Python is interpreted and not compiled, launching a debug session takes seconds. You can make a modification and see the effect of the change immediately.”

(From MacDevCenter.com)

TurboGears is now at 1.0 release, and now has a new leader, Alberto Valverde. Best of luck to Alberto, and kudos to Kevin Dangoor from going from “idea” to “self-sustaining community” in less than 18 months.

The archive of the IRC chat where yesterday’s numerous announcements took place is available here. I’m sure it will be nicely summarized elsewhere by many others who are closer to the details.

There is a lot of interesting tidbits regarding TG and how it will fit into the greater Python web app ecosystem. If TG and its relation to WSGI, Pylons, Paste, CherryPy, etc. are remotely interesting to you, it’s worth a read.

My $.02: Moving forward, TurboGears is staying true to its original integration roots, by providing some glue, a tiny bit of magic, and the assurance that all of its component parts will mesh nicely together.

Python.org has a number of very interesting Success Stories of how various organizations are using Python to solve real world problems. With all of the focus on web development frameworks and such, it’s interesting to see the diverse set of problems that Python is addressing every day.

In our new case study titled Botonomy Uses Python to Create ProjectPipe.com for Web-based Project Management, I give a high-level overview of both the “why” and the “how” behind ProjectPipe.com, our hosted project management solution.

The article talks about the problem that we set out to solve, and walks through one of the more detailed “behind the scenes” overviews of ProjectPipe that we’ve published to date.

There was a bunch of news coming out of the Apple Worldwide Developer Conference (WWDC), but in my opinion, the story with the lowest “press-coverage-to-significance” ratio is around Apple’s iCal Server. It turns out that the server itself is written in Python using the Twisted networking framework.

Yesterday, it was also announced that Apple officially joined CalConnect, the calendaring and scheduling consortium. The iCal Server supports CalDAV, the up-and-coming standard for standards-based calendar and scheduling over commodity web infrastructure. For more info on CalDAV, check out this CalDAV article on NewsForge.
I find this interesting from three perspectives:

1. SMB Market Expansion: Apple’s movement into the calendaring space will provide another viable alternative to Exchange, especially for new businesses. Before WWDC, the rumor mill was buzzing about Apple getting into the Voice-over-IP (VOIP) business. I think that this is the classic Apple play: Take a useful technology that works, package it in an elegant interface, make it easy to use, and then cast the problem so that people say “Why didn’t it always work this way”. An easy to use Calendaring and VOIP solution from Apple would be a game-changing moment.
2. Ruby vs. Python: It puts some context around the announcement that Ruby on Rails will ship with Leopard (OS X 10.5). The bundling of Rails is great news for everyone involved. The Rails community is very much pro-Mac (all of the core commiters, and the vast majority of Rails developers work on Macs (much to the delight of Allan Odgaard, developer of the phenomenal TextMate text editor).

   However, the fact that Apple is building new, high-profile applications using Python should indicate that Apple is not likely to be a one-trick pony when it comes to dynamic languages.

3. Additional validation of Twisted: The fact that Apple is using Twisted as the foundation for something as strategically important as Calendaring should reinforce the well-deserved image and reputation of the Twisted team and the software that they produce.  In time, this is certain to introduce Twisted to the greater IT industry, and make Twisted-based applications much more interesting to the broader market.

Here is the article.  It also has a pretty good comparison between TurboGears and Django at the end of the article.  Django, another Python web framework was the subject of the first part of this two-part series.

The 1.0 Beta of IronPython (Python running atop .NET) is available at the IronPython Workspace Home at gotdotnet.

This is great news for Windows users because IronPython and Monad/MSH (the new Microsoft command line shell) give developers/sysadmins/power users/etc. two very attractive alternatives for scripting and automation.

Down the road, it could be viewed as a legitimate alternative to C# (and CPython) for more ambitious application scenarios as well.

Plus, Microsoft’s formal nurturing and release of IronPython should make a world of difference in Python’s acceptance rate among the “100% Microsoft Shop” crowd.

This is also great for the Python community because it makes Python “not irrelevant” to the scores of seasoned developers who have invested a ton of time and energy becoming one with the .NET Frameworks. They can Embrace python because it Extends their mental investment in .NET.

Embrace and Extend. That has a nice ring, doesn’t it

]]>