RSS
 

Archive for the ‘Elastic Architecture’ Category

Are Amazon’s various “elastic” services elements of an elastic architecture?

17 Aug

If you’ve looked at Amazon’s published web services lately, you’ve noticed that there are a number of “elastic” services available from their cloud.  These include Elastic Block Store (EBS), Elastic Computer Cloud (EC2), Elastic MapReduce and Elastic Load Balancing.

Amazon’s definition of “elastic” centers on massive (through thousands of instances) horizontal scaling of “as many or as few compute instances running (your application) as you want.”  Startup of additional elastic instances is a manual process (which can be largely automated through APIs), and startup time can range from minutes (e.g., for EC2 and MapReduce instances) to longer periods (e.g., EBS and Load Balancing).

Unfortunately, Amazon has not been entirely consistent with their “elastic” tag.  Although all four of those services fit this definition there are several other elastic services worth mentioning in the context of elastic architecture, such as SimpleDB and Simple Queue Service (SQS).   That said, there are elastic choices at most architectural tiers of Amazon’s portfolio, from raw block access (EBS), to logical storage (S3) and database storage (SimpleDB and RDS), at the messaging layer (SQS and SNS) and at the start of the application layer (EC2).

So…if Amazon’s got a comprehensive elastic stack, what’s not to like?  Two things*:

1) The threat of vendor lock-in. If you want to move your SimpleDB-based application to Rackspace someday, how are you going to do that?  If Amazon wants to raise usage rates 50% year-over-year down the road what are you going to do about it?

2) The threat of cloud reversal.  If you get a new CIO, new regulations, acquire/divest major IT resources or just need to fill up some idle racks, how can you pull some or all of your application down from the cloud and back into on premise datacenters?

What’s the answer to these threats?  First, understand the concept of “cloud escrow“.  Second, learn how to build around a cloud-portable elastic architecture and how that helps you negotiate with cloud vendors.  Third, keep reading DivConq.com as we continue to explore these issues!

* = OK, in the “not to like” department, there’s also manual start-up of elastic instances and a weak application/presentation layer – but there are ways around those – we’ll cover these on DivConq in a future article.

Share
 
Comments Off

Posted in Amazon EC2, Elastic Architecture, Other Organizations

 

Elastic Architecture

09 Aug

“Elastic architecture” is a concept you will read about more frequently as time goes on. It refers to computer architecture designed such that applications with different roles in different tiers of an application can each intelligently (and elastically) scale up or down to meet processing requirements.

We are not the first people to name this concept. Yahoo.com’s Eran Hammer-Lahav talked about elastic architecture in an August 2007 blog post. In this post he discussed two intersecting themes: applications that could scale themselves, and tiered deployments that rely on a mix of caching, acceleration and replication to keep up with the layers that are horizontally scaling to meet the current load.

Software architect and trainer Simon Brown also came close to naming this concept in a May 2008 blog post. In this post he talked about a “cloud (that) could migrate your data/apps automagically, depending on where they were being accessed from”. This certainly seems like an application that would require multiple layers to intelligently scale horizontally in multiple geographic locations; that’s an example of elastic architecture.

As you probably know by now, DivConq’s main goal is to promote the adoption of highly scalable, cloud-portable technology in multiple tiers of an application. (For example, using Cassandra as the data store at the same time you’re using an application layer built on an array of high-throughput web servers.) Now that goal has a name and we’re proud to promote the adoption of elastic architecture throughout the IT industry.

Share
 
Comments Off

Posted in Cloud, Elastic Architecture

 

Cloud Portability: Demand It!

24 Jul

By now you’ve been deluged by advertising extolling the benefits of cloud computing: use only what you need, scale up or scale down and take advantage of widely, someday geographically, distributed computers and networks.

However, two simple facts often get swept under the rug:

1) Most cloud providers are trying to lock you in to their stack of application and data providers.

Amazon provides an application stack (EC2 and more) and data stack (S3, SimpleDB, etc.) that isn’t compatible with Microsoft’s application stack (.NET w/ Azure) and data stack (SQL Azure, etc.), and neither are compatible with other clouds such as those from IBM, Google and others.

When you develop an application for a specific stack of cloud application and cloud data storage infrastructure, you tie yourself to the viability and good behavior (pricing, availability, etc.) of that specific, nonportable technology.

2) When you scale up/down you do so at the prices your cloud provider sets.

Unless you are a high-usage customer of a particular vendor’s cloud services you will have little ability to negotiate a price with your cloud.   Even if you are a high-usage customer, your leverage to negotiate will be significantly reduced by the fact that you will be heavily dependent on (locked in by) the application and data stack of you cloud provider.

Developing Cloud Portable Applications

Make no mistake: cloud computing IS an important movement and companies and developers need to start taking advantage of it NOW.  However, there are technologies and architectures you can use to protect yourself from cloud lock-in.  By developing on cross-platform, cloud-ready technologies like Cassandra, Nginx and lighttp rather than the proprietary technologies offered directly by cloud vendors, you gain the ability to:

1) pick up and move your critical applications if you current cloud provider fails to meet its service level agreement (SLA)

2) shop around for price and put pressure on your cloud provider to give you discounts on your hosted services

3) host simultaneously on multiple clouds or your own equipment for the exactly the right combination of worldwide availability and price for your enterprise

DivConq Provides A Bridge to Cloud Portability

In our founding post, we dedicated ourselves to technology discussions that involved “highly distributed, heterogeneous systems”.  If you solve that challenge, and two or more of your systems are clouds, you’ve effectively solved cloud portability.  Please stay tuned as we continue to explore and explain the generation of technology that will bridge the cloud portability gap.

lighttpd
Share
 
Comments Off

Posted in Cloud, DivConq, Elastic Architecture

 

Web Server Threading Models

18 Jul

Being very performance minded I’d like to take a tangent to server performance. Server performance is tightly connected to the choice of threading model. In particular I’m referring to the threading model of dynamic web pages: PHP, ASP, JSP, Rails, etc. About the worst thing you can do for performance is to have a thread just waiting. Just throwing more threads at the problem does not resolve it – though it can help. But preventing any waits at all is the superior solution by far.

At a high level there are three thread modeling choices in server design:

1) A single thread reads the request, then calls the script that generates the page and waits for the script to complete after which any final writes are completed. The thread stays with the request from the first byte read to the last byte written. There are ways to make this model even less efficient, but lets leave it at that.

This approach can result in a lot of wait time on the thread while it waits for request buffers to read and waits for ACKs when writing response buffers.

There is also an inherent issue in that all the data about the request must be collected up front before the script is called. This means waiting for all the request buffers to be delivered and, in the case of large requests (file uploads) caching the request on disk.

There are two problems with that:

a) memory (RAM or disk) is being filled up by request data and often by response data too

b) data that gets on disk may be vulnerable since it will not typically be encrypted

2) Another approach – called async I/O – is to keep a pool of threads that is used to read requests a buffer full at a time. The thread is active only long enough to process that one buffer and then the thread goes back into the pool. Once the request is completely assembled a script is called and the server waits for the script to complete.

This approach gets past the issue with waiting the reads and writes (when response buffers are used) but still has the memory issues, security issues and the wait on the script. Another way to state that is the script *must* return a complete response and that the server dedicates at least one thread to the script for the entire duration of the response generation.

An exception is when response buffering is not used, however, when response buffering is not used the async I/O benefits are lost for the output.

Note the server’s thread line has holes in it now – a good thing because it frees resources.

3) Another approach – called full async – uses a pool of async I/O threads for reading and writing to the client. However, it also allows for the script generating the response to be fully async.

Note another hole appears during the run of the script because the script has made an async operation itself. This capability is very important now that we use web services so often – it makes no sense to block a thread while calling a web service.

The most evolved examples of full async are perhaps better named streaming async. Streaming async gets around the problem of caching files for upload or download – while still retaining the async I/O model.

I myself have developed a couple of streaming (full) async servers at my work, unfortunately they are not open source. At some point I’ll discuss streaming async in more detail.

The full async server concept is gaining ground. Some examples are the new comer nodejs which does not send a response until you call ‘end’ on the response object. Meaning the script’s thread can exit without the response being sent. This is not at all like PHP, ASP or other standard web servers.

Another example is upcoming Ruby on Rails version 3, check out the
async_sinatra project and async_rails project. They are going so far as to make even calls to the database async – a great idea! Keep in mind my articles about Nginx when checking out Thin.

Yet another example is the Kayak HTTP Server’s responder interface. Kayak is a Dotnet based web server.

In the world of Java, the soon to be released Jetty 7 has extended the Continuations API (previously only used with Comted) for all web scripts so now Java 3.0 servlets can be full async as well.

From the examples we can see that only in the last year has the full async model become trendy, and for good reason, it is very important for scalability of a web server.

Share
 
Comments Off

Posted in Beginner, Elastic Architecture

 

Why Cassandra

09 Jul

In my previous two posts – Simple, Secure and Speedy part one and part two – I pointed out that one of the most limiting factors in scaling web applications is the database. So while we could keep it simple and reasonably secure using commonly used components (PHP, MySQL, lighttpd, Nginx), the scalability story is where the issues begin. In part two I pointed out that both the application servers and the reverse proxy servers could scale fairly well. But what about the database?

Architecturally there are three topics worth considering when looking to scale a database. First is performance, second is local availability, and third is global availability. Clustering a relational database, such as MySQL, does provide performance and local availability – but it does not provide global availability. In other words, it does not span data centers and geography.

There are solutions for spanning data centers with relational databases – SQL Server has some replication features to help, as do a few other projects. From a cloud perspective Amazon Relational Database Service is an interesting solution to the problem.

While I’m glad there are possible solutions out there, my main issue is that relational databases really are not designed to be distributed. I think we can do better. As a veteran of nosql (aka post-relational) database development I think that ‘nosql’ style databases will be easier to develop on and deploy/manage in a distributed (multi-data center / global) world. Especially if you want to maintain provider neutrality or if you want on-premises (or hybrid) deployments.

BTW, if you think nosql hasn’t been around long – think again – MUMPS was an excellent example of nosql concepts and is alive and well in the form of GT.M and at the roots of InterSystems Caché®. There is even multi-data center support. As much as I appreciate these projects, and the many other nosql projects out there, at the end I think Apache Cassandra has some of the best ideas in terms of balance of speed and accuracy and overall good design.

As such, you’ll be seeing more many blogs about Cassandra. Do I see any drawbacks to Cassandra? Well yes, biggest of which is secondary index support is all manual – but that is par for the course with nosql. And lack of stored procedures, though Hadoop and Pig kind of address that. Other than that my biggest gripe if the poor naming of the data model. The words ‘columns’, ‘rows’ and ‘super’. If you feel this way too and are still trying to get Cassandra’s data model then consider this revised naming scheme – once you get it then moving back to the columns/super columns terminology may be easier.

Here is the short and sweet intro to Cassandra with the revised names:

Cassandra can hold one or more data stores per node. Each data store is named. Each data store has one or more families of data. Each family contains zero or more family keys. A family key is always a string value. When present a family key contains one or more field keys. The data stores and the families they contain must be given a name in the storage-conf.xml file. Furthermore the data type of the field key must be declared.

There are two kinds of families: Standard and Extra. Using the Cassandra CLI you can interact with the two families as such:

Standard Family

set <store_name>.<family name>['<family key>']['<field key>'] = '<value>'

Extra Family

set <store_name>.<family name>['<family key>']['<extra key>']['<field key>'] = '<value>'

Again – the ‘<store_name>.<family name>’ part needs to be declared in the config. The data type of the family key is always string. The data type of the field key (and the extra key, if present) must also be declared.

The definitions look something like this:

<Store Name="<your store name>">
<Family Name="<your family name>" CompareWith="<field key type>" />
<Family Name="<your family name>" Type="Extra" CompareWith="<extra key type>" CompareSubcolumnsWith="<field key type>" />
</Store>

That’s it. There are no other family types, no other configuration to worry about – very simple once you take the words ‘column’, ‘super’ and ‘row’ out of the mix. Look back at the various descriptions of the Cassandra data model and see if there is more clarity now.

Also, these diagrams might help with the terminology – thanks to Chaker Nakhli for that helpful article.

On this blog we will provide some real world examples of smallish applications modeling data in Cassandra.

Share
 
Comments Off

Posted in Amazon EC2, Cassandra, Elastic Architecture, Hadoop and Pig, Introduction, MUMPS, nosql

 

Simple, Secure and Speedy – Part Two

05 Jul

Amazon’s EC2 (Elastic Compute Cloud) enables an user to deploy a fully customized Linux or Windows server in the Amazon cloud. Beyond the security provided by the built-in (Windows or Linux) firewall, EC2 provides another layer of firewall called a security group.

A security group may be configured to filter IP traffic – to allow access to only certain ports from certain Internet address ranges. IP traffic that does not pass the filter rules will never even touch the server. All servers running in a security group assume the same filter rules.

Furthermore, a security group may be configured to allow access only from another security group. Thus enabling very secure multi-tier deployments in Amazon’s EC2.

private tier in Amazon's EC2

Read the rest of this entry »

Share
 
Comments Off

Posted in Amazon EC2, Beginner, Cassandra, Elastic Architecture, Gateway, lighttpd, Nginx, Reverse Proxy

 

Simple, Secure and Speedy – Part One

03 Jul

Securing a web server may sound like a daunting task.  It may be tempting to think that complex solutions will provide the most security. This is not always the case, sometimes a simple solution can provide a lot of protection.

A web server is one of the most visible targets for attackers for three reasons:

  1. The sure popularity of HTTP
  2. The bevy of vulnerabilities found in misconfigured web servers
  3. The sometimes poor quality of ‘CGI, etc’ software running on the server

So naturally great care should be taken to secure the web server. But what if the web server should become compromised? Have you increased your attackers surface? Consider this diagram:

Once compromised the web server now provides the attacker multiple new targets such as LDAP, MySQL, and SysLog. A very simple addition to the diagram, the reverse proxy, will put the attacker back to square one – again battling to break into a web server with little else gained.

So your attacker can do one of two things:

1) Deface your web site or otherwise abuse that single server. While this is certainly not an attractive proposition, it definitely beats the news that sensitive data or systems are under attack.

2) Resume the attack and attempt to hack into the next web server – the one in the internal network. To further frustrate the attacker, choose a different web server for the internal network. Whatever vulnerabilities they used to compromise the first web server will likely be useless against this new web server.

Example Configuration

Reverse Proxy Server: consider Nginx a widely used but very light weight web server. The base install includes reverse proxy features. Minimally add a ‘proxy_pass’ setting to the location in the Nginx configuration.

server {
  listen   80;
  server_name  localhost;
  location / {
    proxy_pass http://[private server address]:8000;
   }
}

Private web server: consider lighttpd a light weight HTTP server well suited to running with PHP through the FPM module in PHP (as of PHP 5.3).

Any web server in the private network would work, of course. And the Nginx configuration would be more complex if you need to support SSL, or if you want static files to cache in the DMZ zone. But overall this is a very simple way to get considerably more security for your sensitive systems and data. And, as it turns out, it also scales well – more about that in future posts.

Next Post: The same reverse proxy techniques can be used in in Amazon’s cloud.  (Read now.)

Share
 
Comments Off

Posted in Beginner, Elastic Architecture, Gateway, lighttpd, Nginx, Reverse Proxy

 
Newer Entries »