Today still a lot of service offerings are sold by a flat-rate "all you can eat" subscription model. That’s simple to understand and simple to implement. But is it the right way to sell services? Especially if you could split off add-ons? When you watch companies growing in the cloud you see that tweaking your offering and finding the right business model becomes vital for building a successful business. We have enabled companies in on-premise scenarios to achieve this during the last 25 years. As we have been moving into the cloud and started offering this flexibility to cloud companies (or yet to become cloud companies) we have gone through rebuilding our system for the cloud in the right way. In this talk we want to share with you lessons learnt from building our cloud service. We’ll start off with some fundamental properties of distributed systems and will analyze the impact on the offering. We’ll look at the requirements for such system and will build an architecture to these requirements by including the fundamental mechanics of the cloud. By taking care of the CAP-theorem we’ll find the right decision to adapt the classical scenarios to the cloud.
6. Eventually Consistent
“Real internet systems are a careful mixture of
Consistency and Availability subsystems”
- Dr. Eric Brewer
Professor, UC Berkley, Co- founder Inktomi
“Eventually Consistent - Building reliable
distributed systems at a worldwide scale demands
trade-offs between consistency and availability”
- Werner Vogels, CTO Amazon.com
7. Checking Cloud Compatibility
License Models / Authorization
• Category 1
• Quasi stateless / autonomous - harmless
• Perpetual
• Expiry date
• Category 2
• Asynchronous - mostly harmless
• Post paid
• Category 3
• Synchronous - strict consistency!!
• Max Concurrent Use
• Depleating
8. Conclusions for our Problem Domain
Some Classic License Models do not SCALE
- Problem: require a globally limited Resource
- This inherently requires STRICT CONSISTENCY!
Classic case for „we always did it like this“ meets
cloud.
Going cloud is not only a technical challenge!
It can require change in offering because of
technology
9. So what did we do?
Work with business owner to find the right solution
Apply what we learnt before – explore how weak
consistency can help.
10. Converting…
Map to Eventually Consistent Approach
No sharp Cut-Off in distributed license resource data!
• Eventually consistent means no strict limits can get
guaranteed. Some ‘over usage’ might happen.
• In case strict limits are required, you will have to accept
slower response times and greater impact on disconnects.
Strict consistency leads to reduced QoS for the end-user.
11. Paradigms of our Cloud Architecture
No Delay!
speed, bandwidth & reaction time of service must not suffer just
because the service is licensed/tracked.
Effects of “slowness”
Amazon: 100 ms delay caused a 1% drop in revenue.
Google: 400 ms delay caused a 0.59% decrease in search requests per user.
Yahoo!: 400 ms delay caused a 5-9% decrease in traffic.
see e.g. http://goo.gl/ADQuR
Autonomous nodes - Local intelligent
caching!
12. Paradigms of our Cloud Architecture
Scale with the customer!
No additional infrastructure because of licensing system.
Stateless modules
Plug into each platform!
19. in Detail
Client Node
- Feature X, TTLx - Login Event
- Feature Y, TTLy - Logout Event
Authenticate
AuthMap Session
Directory
EMS SCC Service
Data Engine
Provision
Contract
Data
Store
Data
Store
Amazon EC2
20. Key Take Aways
Distributed systems require different thinking
• Connections are not granted
• Autonomous components help
Moving to the cloud might have impact on what you
can deliver
• Your cloud offering might have to be different from the classic
• Work with your business owner to get this straight early
Existing Customers might need to be educated
• Customer expectations are driven by what they know
• You might have to lead them thru the same process
22. References
CAP Theorem
http://goo.gl/37dms - Nice intro from Julian Browne
Eventually consistent
http://goo.gl/yTCpW - Good starting point for consistency
considerations. Blogpost from W. Vogels, CTO Amazon
Google’s timing experiments / WPO
http://goo.gl/ADQuR