Friday, June 6, 2014

Everything I needed to know about Software Architecture...I learned from Google App Engine


Software Architecture is a sweeping field of study with an immeasurable range of opinions on how best to approach its execution. While designing a cloud-hosted project involving Google App Engine, I came to realize that there are quite a few similarities between approaches to App Engine development and those applicable to Software Architecture, generally.

Below, I've explored a few concepts that get at my own observations of the connections between Google's cloud application platform and the larger school of thought. If you're familiar with one, but not the other, fear not! Descriptions of each App Engine component are provided, with an explanation of the corresponding architectural concept appended in italics.

What is Google App Engine?

Simply put, Google App Engine (GAE) is a service provided by Google for running applications on their infrastructure. That said, while writing for Google App Engine initially appears to be obvious, adopting an App Engine frame of mind can be a transformative experience.

Divide and Conquer... then Divide Again

Google App Engine was designed to run web applications. Traditionally web applications would start when a request came to the web server, do something, return something, and then end. Most web applications never run for more than a few seconds because after more than a few seconds web surfers conclude that something’s wrong or they move on to something else. Even web applications that appear to be long-running (like Gmail for example) are made of many very small applications (tasks) that run in the background and supply data to their web front-ends. If a task requires more than a few seconds to complete, break it down into smaller pieces that can complete very quickly.

- when creating an application, break down larger tasks into progressively smaller pieces until those pieces a very simple and can each be written quickly; if a task is too complex to complete in a relatively short period of time (for example, 4 hours), then it needs to be broken down into smaller tasks that can be completed quickly. Said another way, if a junior developer can’t complete the task in a day, the task needs to be re-architected, typically by sub-dividing that task even further

Many hands...

The concept of breaking down larger projects into small tasks naturally lends itself to specialization. That is, instead of a single large, monolithic application that provides all of the functionality that the application needs, applications written for Google App Engine tend to be highly specialized. That is, instead of one program providing X different functions depending on how it was called, it is typically more efficient to provide X very small programs that each only perform a single action. That’s not to say that all X of these programs are user-facing -- doing so would incur a huge amount of overhead that would multiply the effect of network latency on the end-user’s experience. Rather, it’s often times much more efficient to call additional programs asynchronously and in parallel.

- from a project management perspective, given a sufficiently deconstructed project many developers can work on small, manageable components in parallel. Often times, much of the task-oriented, small-scale development work can happen simultaneously

The engines... they can’t take anymore!

What happens if there’s more work to be done than can happen in a few seconds? App Engine has a service -- Task Queues -- that can help. A Task Queue is a place where Tasks can be queued up for background execution. Google App Engine continually watches the Task Queue and; when it encounters a task to perform, it runs the task as a separate request. Tasks are then removed from the Task Queue as they’re completed. Tasks can, and often do, run in parallel so they’re a great compliment to App Engine’s web processing model. Moreover Tasks can enqueue additional Tasks, that is one Task can handle some portion of a large workload, process for a few seconds, then enqueue a new Task to pick up where the current Task left off. A common concept with background processing and Task Queues in general is to provide the information that Tasks will need later on without having to spend time retrieving data, recomputing values, etc.

- understand that individual developers have likes and dislikes, strengths and weaknesses, and limited processing capacity. Provide them with the tools they need to do their job, but also provide them with the tools and ability to hand off work to other developers. The most important goal is to get the work done quickly and efficiently; how it gets done can often be left to empowered developers to decide

There’s an app for that!

Google App Engine provides a healthy list of libraries to perform specialized functions within the context, rules, and scope of the App Engine runtime environment. For example, there are libraries to store data in memory shared across multiple calls of the application (Memcache), fetch resources from remote systems (URLFetch), interact with durable storage solutions (Datastore, Blobstore), process images (Images), send email (Mail), and much more. Some of the functions provided by the App Engine runtime environment work (much!) faster than custom-written code while other functions are simply prohibited except through the Google-provided libraries.

- provide your developers with the tools (applications, hardware, resources, etc.) they need to be successful. Often the right tool can greatly enhance the speed with which your team can deliver a working solution. Without the right tools projects can range from disastrously slow to simply impossible

You can’t get there from here...

Google App Engine provides loads of functionality, but there still exist some restrictions. For example, there are restrictions on what can be done using network sockets and what can be done with regards to reading and writing files on the filesystem. As a result, some applications simply aren’t a match for App Engine. However, Google App Engine isn’t the only infrastructure solution available through Google Cloud Platform. For example, Google Compute Engine (GCE) provides a virtual Linux environment that can run just about anything that’ll run on a Linux system.

- recognize that different problems often involve different solutions.These solutions may involve talent acquisition, resource procurement, or something completely different. Only to the person whose only tool is a hammer does every challenge look like a nail

Nothing remains constant except change itself

Google's engineers are constantly improving Google App Engine. With new releases every few weeks limitations that apply at one point in time may no longer apply after a new release. For example, at one point, application runtimes on frontend Google App Engine instances were limited to 30 seconds; a while later, the runtime limit was raised to 60 seconds. Also, at one point it was not possible to encrypt applications hosted on Google App Engine at custom domainnames via HTTPS -- only application.appspot.com URLs could use HTTPS; however, a later release lifted this restriction by allowing administrators to supply their own custom SSL / TLS certificates.

- anything relating to technology, including software architecture, continually changes. Developers, architects, technologists, engineers, system administrators, and programmers must constantly re-educate themselves. Constructs that work today may not work tomorrow. You owe it to clients, your developers, your organization, your peers, and yourself to continually survey and study technology and development best practices

In conclusion, while there are many ways to develop the architectural components of an application and there are many ways to host web applications, there are parallelisms between the two. Breaking down complex concepts, leveraging concurrency, and employing the right tools apply, conceptually, to both Software Architecture and Google App Engine such that a detailed study of one often leads to insights about the other.

Wes Dean, a Google Apps Certified Deployment Specialist and a Google Apps Trusted Tester, is the CEO of KDA Web Technologies, a specialist in Google Cloud Platform developmentand a Google Apps Authorized Reseller. To learn how KDA Web Technologies can help your organization, visit www.kdaweb.com.

No comments:

Post a Comment