The document discusses next generation application architectures using open source tools. It describes how current infrastructure approaches are inefficient and advocates for focusing on applications first and abstracting containers. This would allow for self-optimizing, self-healing applications that can be built, tested and updated faster. The document outlines how technologies already exist to enable global application fabrics running applications side-by-side on shared servers with automated configuration and updates. It envisions faster development cycles by focusing on what matters most: users, developers and applications.

1. Innovation & Next Generation
Application Architectures
... with Open Source!
Jesse Noller
Principal Engineer, Rackspace
developer.rackspace.com
Brandon Philips
CTO, CoreOS
coreos.com

2. Jesse Noller
@jessenoller
Principal Engineer,
Rackspace

3. Brandon Philips
@brandonphilips
CTO, CoreOS

4. Infrastructure is sort of … dumb, or at least
annoyingly so.

5. Individuals or Collections
Single Purpose
Single Application

6. … Re-configure? Pave over, usually.

7. But why do we do this?

8. It’s a bit of a infrastructure flea market.

9. Smarter Infrastructure.

10. Open Hardware Open Source API
OnMetal

12. It’s getting smarter.

13. … But!
It’s hard to learn, and hard to build.

14. We believe in a better future.

15. Stop thinking about infrastructure.

16. Invert your thinking

17. Applications come first.

18. name: web
replicas: 5,
labels: [ env=production ],
uses: [ postgresql ],
images: [
web:v2014-07-23,
redis:2.8.13,
],
requirements: {
memory: 2GB,
networkIO: 5MB/s
}

19. Self-optimizing. Self-healing. Self-organizing

20. name: web
replicas: 5,
labels: [ env=production ],
uses: [ postgresql ],
images: [
web:v2014-07-23,
redis:2.8.13,
],
requirements: {
memory: 2GB,
networkIO: 5MB/s
}

21. Build, test, pivot faster.

22. name: web
replicas: 5,
labels: [ experiment=cache ],
uses: [ postgresql ],
images: [
web:v2014-07-23,
redis:2.8.13,
],
requirements: {
memory: 2GB,
networkIO: 5MB/s
}

23. The “stack” is a distraction.

24. Can we abstract containers?

25. We’re not as far off as you think

26. Google/Twitter/etc has this already & has been
describing it for years

27. Containers (cgroups, namespaces)

28. Cluster configuration (Google Chubby)

29. Scheduling (Omega, Aurora)

30. Load balancing

31. Internal and external monitoring

32. Access Control throughout the system
(unknown)

33. So, we’re (sort) of getting there…

34. We’re just on the brink.

35. It’s not about how much memory is in your
computer.

36. We need companies and partners to go and
create this future.

37. We’re stuck in a box where we want to think
about servers.

38. kernel
systemd
ssh
docker
python
java
nginx
mysql
openssl
app
distrodistrodistrodistrodistrodistrodistro

39. kernel
systemd
ssh
docker
python
java
nginx
mysql
openssl
appdistrodistrodistrodistrodistrodistrodistro

40. … But today has its demands and it must be fed.

41. Applications need to be repackaged for isolation
in containers

42. python
openssl-A
app1
odistrodistrodistrodistrodistrodistr java
openssl-B
app2
java
openssl-B
app3
kernel
systemd
ssh
docker

43. ubuntu
jvm
app1
redhat
python 2.6
app2
debian
nginx
app3
kernel
systemd
ssh
docker
odistrodistrodistrodistrodistrodistr

44. app1 container
app2 container
app3 container
CoreOS
odistrodistrodistrodistrodistrodistr

45. Applications need to be configured with
clustering in mind

46. Applications need to be automatically built from
source…
… and available as containers

47. name: web
replicas: 5,
labels: [ env=production ],
uses: [ postgresql ],
images: [
web:v2014-07-23,
redis:2.8.13,
],
requirements: {
memory: 2GB,
networkIO: 5MB/s
}

48. name: web
replicas: 5,
labels: [ env=production ],
uses: [ postgresql ],
images: [
web:v2014-07-23,
redis:2.8.13,
],
requirements: {
memory: 2GB,
networkIO: 5MB/s
}

49. name: web
replicas: 5,
labels: [ env=production ],
uses: [ postgresql ],
images: [
web:v2014-07-23,
redis:2.8.13,
],
requirements: {
memory: 2GB,
networkIO: 5MB/s
}

50. Rethink & focus on what is most important:
Users, Developers, Applications

51. Define [success]

52. !
No debates on what configuration management
tool is the best today.

53. “DevOps is dead.”
!
- Abraham Lincoln

54. Pipeline of code to containers to production

55. Servers are shared & applications run side-by-
side

56. Configuration is global and atomically updated

57. When everyone can do this.

58. Faster Idea Test Success Cycles

59. Hint: It’s not Platform as a Service.

60. No More bizarre and byzantine decisions.

61. It’s not for everyone yet.

62. How do we migrate to this?

63. What does the industry look like?

64. You focus on your ideas.
Global application fabric.

65. Events this Week

66. Today 12:45 pm - 1:10 pm
The new developer+ program
@ the Rackspace Booth

67. Today 3:45 pm - 4:15 pm
Intro to CoreOS Talk
@ the Rackspace Booth

68. Tomorrow 6:00-8:30 PM
CoreOS + Docker OSCON Meetup
Brought to you by New Relic & Rackspace - http://goo.gl/ZmebT3

69. Innovation & Next Generation
Application Architectures
... with Open Source!
Jesse Noller
Principal Engineer, Rackspace
developer.rackspace.com
Brandon Philips
CTO, CoreOS
coreos.com