AWS Tech Summit for Developers and ArchitectsBerlin, 2011-05-16

Lessons Learned fromConverting a Web Application

to Multitenancy and Deploying it toAmazon Web Services

using Scalarium

http://twitter.com/thomas_witt

Thomas Witt

@thomas_witt

http://www.infopark.de/

Since 1997 …

Director Product & Business Development

Great Websites run InfoparkFounded in 1994 in Berlin

CMS, CRM and Online Marketing Software

Large Websites for Enterprises

http://www.infopark.de/references

References

http://www.infopark.de/references

References

infopark.de/references

What are we going to learn …

Why did Infopark move to «The Cloud»™?

How did we do it?

What did we learn from it?

Why?(You will be cloudified. Resistance is futile.)

Enterprise Software Installation sucks.

http://www.alexa.com/siteinfo/cortalconsors.de

http://www.alexa.com/siteinfo/bundestag.de

http://www.alexa.com/siteinfo/munich-airport.de

Modern Web-Sites have to be cloud

based.

http://aws.amazon.com/

Our partner

Multitenancy(Yes, we scale!)

“

http://en.wikipedia.org/wiki/Multitenancy

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).

Enabling Multitenancy

Create a "shared nothing" architecture

Move all configuration into the database

Extract background tasks

Choose database tenantwise

Implementing DB switching is easy

tenant = request.host.split('.').first

begin @@db ||= CouchRest.database(tenant)rescue raise "tenant name '#{tenant}' doesn't exist"end

SaaS Cluster

AZ 3AZ 2AZ 1

System Architecture Fiona on SaaS

EC2: Fiona, OMC, DB, Search

EC2: Fiona, OMC, DB, Search

EC2: Fiona, OMC, DB, Search

EC2: Fiona, OMC, DB, Search

EC2: Fiona, OMC, DB, Search

EC2: Fiona, OMC, DB, Search

Elastic Load Balancing: *.saas.infopark.net

Scalarium

S3: Assets (Blobs)

SES:E-Mail

DB Backup Server

Redis/Resque

CustomerAZ 1 AZ 2

EC2:Rails,

DB Replica

EC2:Rails,

DB Replica

Elastic Load Balancing:customer.com

S3

+CloudFrontCDN

GitHub

Hoptoad

New Relic

http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html

Use multiple Availability Zones!

Database(Choose wisely)

Problems with SQL databases in the cloud

Bottleneck

Doesn‘t scale

Single point of failure

Adding new Replicas

Consistent backups

Recovery times after crashes

SQL databases are not built for the

cloud.

http://en.wikipedia.org/wiki/CAP_theorem

NoSQL databases ARE built for the

cloud.… by trading off consistency for partition tolerance

http://couchdb.apache.org/

Database backend

Advantages

Simple handling

Better replication

Stability and reliability

Schemaless

Lots of flavours

CouchDB/BigCouch, SimpleDB, MongoDB, …

We have chosen BigCouch.

Automatize!(Scalarium is your friend)

http://www.opscode.com/chef/

Your server – à la carte

Auto Healing (and scaling)

http://www.scalarium.com/

Automatize using Scalarium

Automated Machine Installs

No hassle with AMI Images

Always install from scratch

Using Chef Recipes

Monitoring and Scaling

Auto Healing

Time Based Scaling

Load Based Scaling

Security(… there's lots of interesting data in the cloud)

https://aws-portal.amazon.com/gp/aws/developer/account/

Have multiple AWS accounts

IAM

http://aws.amazon.com/mfa/

Use MFA Devices

Security is important!

Have multiple AWS accounts

Use IAM• Rotate your keys• Use an MFA Device• Lock up your master account

Clear concept how to handle policies, accounts, groups

Have lots of Account/Key Pairs with restricted access

Automatize everything• Security Groups• Regular Firewall checks• Account creation / deletion

People(The Human Factor)

“I don't «own» my data anymore.

“What about data privacy?

“Is your security good enough?

How can I trust you?

“My job went to SaaS!

Have good answers to these questions.

(Try to rationalize the discussion)

Disadvantages?What‘s missing?

Disadvantages? What‘s missing?

Amazon

Automated creation of multiple accounts with separate billing

API for Billing

Scalarium

Access Rights

Security Groups

MFA Support

Have a scalable multitenancy architecture

Automatize everything

Don‘t forget The Human Factor

Conclusion

Infopark AG • Kitzingstraße 15 • D-12277 Berlin • www.infopark.de • info@infopark.de

thomas.witt@infopark.de+49-151-140690-23

Twitter: @thomas_witt

Thomas Witt

That's a wrap!

Thank you!

Director Product & Business Development

Twitter: @infoparkfacebook.com/infopark