Spring Boot & Spring Cloud on PAS- Nate Schutta (1/2) at SpringOne Tour Chicago

1. ♥
@ntschutta
ntschutta.io
Nathaniel Schutta

2. Ah Spring!

3. Anyone remember the
days before Spring?

4. It was a dark time…

5. Some of us called it Winter…

6. It is practically cheating!

7. But now we have “the cloud”!

8. What does this mean for
our Spring apps?

9. Where should we run them?

10. Why PAS?

11. The Value Line.

12. What would you say, you
do around here?

13. Where do you spend
most of your time?

14. Coding?

15. Wrangling servers?

16. Meetings?!?

17. Forrester Business Technographics Global Developer Survey, 2016
13%
18%
34%
33%
25%
24%
42%
31%
23%
26%
30%
26%
15%
17%
19%
18%
7%
7%
9%
6%
10%
5%
3%
4%
4%
None
<15 Min
15-59 Min
1-2 Hr
3-4 Hr
4+ Hr
Writing new / changing existing
code
email
miscellaneous tasks
deploying code
configuring infrastructure

18. 58% of developers spend an
hour or more a day coding.

19. Only 28% spend 3 or more
hours a day writing code.

20. How much time do
you spend on email?

21. 38% spend at least an
hour a day on e-mail!

22. "

23. ( °□°)

24. How much time do
you spend on Slack?

25. 30% spend and hour a
day deploying code!

26. #

27. 29% spend and hour a day
configuring infrastructure!

28. Where would you say the value
line is in your organization?

29. Where do your customers want
you to spend your time?

30. Where do you want to be
spending your time?

31. It isn’t just developers.

32. Operators want to operate!

33. Forrester Business Technographics Global Developer Survey, 2016
13%
14%
16%
21%
21%
24%
30%
30%
29%
32%
30%
27%
32%
28%
22%
18%
14%
10%
12%
8%
10%
7%
4%
5%
3%
None
<15 Min
15-59 Min
1-2 Hr
3-4 Hr
4+ Hr
Writing new / changing existing
code
Building or integrating code
Debugging / production support
Designing new functionality
Unit testing

34. 46% spend an hour plus debugging
or on production support issues.

35. Why is that?

36. Again, where does your org
want you investing your time?

37. Today we have a number of
options at our disposal.

38. Containers. Platforms. Serverless.

39. IaaS
Containers
Container
Container
Scheduling
Primitives for
Networking,
Routing, Logs and
Metrics
Platform
Application
Container Images
L7 Network
Logs, Metrics,
Monitoring
Services
Marketplace
Team, Quotas &
Usage
Container
Serverless
Function
Function Execution
Function Scaling
Event Stream
Bindings
Container
Developer
Provided
Tool
Provided

40. Different levels of abstraction.

41. Hardware
IaaS
Containers
Platforms
Serverless
More Flexibility
Fewer Standards
Lower Complexity
Operational Efficiency
Push as many workloads up the stack as feasible.

42. What do you want to be
responsible for going forward?

43. When the platform does more, you
spend more time delivering code.

44. The further up the stack you go, the
less time you spend on plumbing.

45. Ultimately, you have to do what
is right for your needs.

47. Orchestration is fantastic if you
need to run on a specific port.

48. Many 3rd party apps are
delivered as Docker images.

49. But that doesn’t mean it is the
right spot for every workload.

50. — Adam Wright
The prevailing mythology is you should
"containerize" everything and give it to a
container orchestrator to run, but why?
They had one problem, "Run an app". Now
they have two, "Run a container that runs
an app" and "maintain a container".
https://news.ycombinator.com/item?id=16332184

51. https://mobile.twitter.com/samnewman/status/952610105169793025

52. https://mobile.twitter.com/starbuxman/status/959366771462496256

53. Just want to push an app?
Application Platform FTW.

54. Consistency from
laptop to production.

55. Just have a snippet of code to
execute when an event happens?

56. Functions are your friend.

57. Even less for you to manage.

58. The challenge is picking the
right tool for the job.

59. With great flexibility comes
great responsibility.

60. Development complexity.

61. Do you want developers
thinking about OS patches?

62. Or just pushing apps?

63. https://mobile.twitter.com/onsijoe/status/598235841635360768?lang=en

64. Operational efficiency.

65. How many operators does it take to
manage a bespoke environment?

66. Flexibility vs. standardization.

67. Guardrails aren’t shackles.

68. They are designed to protect you.

69. How do you want to allocate
your resources?

70. Do you know what OS your
application is running on?

71. Do you care?

72. What *should* you care about?

73. Where is the “value line” for you?

74. We want to get out of the business
of “undifferentiated heavy lifting”.

75. Focus on business problems,
not plumbing problems.

76. Choose the option that
fits the problem.

77. Push as many workloads as you
can up the abstraction hierarchy.

78. vSphere Openstack AWS
Google
Cloud
Azure &
Azure Stack
Shared Services
Shared Security
Shared Networking
Logging & Metrics / Services Brokers / API Management
Credhub / UAA / Single Sign On
VMWare NSX
Embedded Operating System (Windows / Linux)
Application Code & Frameworks
Buildpacks / Spring Boot / Spring Cloud / Steeltoe
PAS
Pivotal Application
Service
PKS
Pivotal Container
Service
PFS
Pivotal Function
Service
Pivotal Services
Marketplace
Pivotal and
Partner Products
Concourse

79. Any App, Every Cloud, One Platform.

80. PAS - runtime for apps.

81. Java, .NET, Node, etc.

82. PKS - runtime for containers.

83. Kubernetes.

84. PFS - runtime for functions.

85. https://projectriff.io

86. Marketplace - all the other
things your app needs to thrive.

87. Run it on prem or public cloud.

88. Provider agnostic.

89. Hybrid cloud.

90. Multi cloud aka Polycloud.
https://www.thoughtworks.com/radar/techniques/polycloud

91. Spring Boot ready made for PAS.

92. Think about all the things a
cloud native app needs…

93. Service registry. Circuit breaker.
Config server. UAA.

94. Spring Cloud Services!

95. Don’t forget monitoring! Turns
out that’s pretty darn important.

96. PCF Metrics and Loggregator.

97. Of course you should also
leverage Spring Boot Actuator.
https://docs.spring.io/spring-boot/docs/current/
reference/html/production-ready-metrics.html

98. Not to mention what the
Marketplace offers!

99. Common theme running
through Spring and PCF…

100. Eliminate repetitive tasks.

101. Who here likes boilerplate code?

102. Java has…a fair amount of it.

103. $

104. Remember when Ruby and
Rails showed up?

105. Simplified a lot of things.

106. Java has improved!

107. Lombok anyone?
https://projectlombok.org

108. Spring Boot is opinionated.

109. Minimize the fuss.

110. Spring + PAS frees you to focus
on delivering. Not plumbing.

111. Spring Framework Spring Security Spring Data Reactor Spring Batch Spring Integration
Spring Boot
Spring Cloud
Spring Cloud Pipeilnes

112. PAS is at it’s best with stateless
workloads: web apps, REST APIs etc.

113. Databases, search engines, etc.
better fit for PKS.

114. Why is PAS such a good
fit for Spring apps?

115. Twelve Factor App.
https://12factor.net

116. Characteristics shared by
successful apps.

117. 1. One codebase in version control,
multiple deploys.
2. Explicitly define your dependencies.
3. Configuration must be separate from
the code.
4. Backing services are just attached
resources.
5. Build, release, run.

118. 6. Stateless - share nothing.
7. Export services via port binding.
8. Scale via process.
9. Start up fast, shut down gracefully.
10.Dev/Prod parity.
11.Logs as event streams.
12.Admin tasks run as one off
processes.

119. Fair amount of repetition in a
typical microservice.

120. Spring Boot simplifies 12
Factor app development.

121. Dependency management.

122. Boot starters, first class Maven
and Gradle support.

124. Property configuration.

125. Autconfig removes boilerplate
application configuration.

126. Backing services.

127. Build, release, run.

128. Environment and @Profile:
adapt from dev, stage to prod.

129. Makes app config available in
certain environments.

130. Port Binding.

131. Logging.

132. Actuators: metrics/monitoring,
integrates into PCF console.

133. Deployment.

134. Spring Deployment Profiles.

135. Transition between environments
without recompiling/rewriting.

136. Cloud Foundry automatically
activates the cloud profile.

137. Profiles let you describe sets of
beans differently from env to env.
https://docs.spring.io/spring-boot/docs/current/
reference/html/boot-features-profiles.html

138. H2 in dev, PostgresSQL in prod.

139. Decision based on the
active profile or profiles.

140. Spring Cloud Connector for
Cloud Foundry.

141. Bring CF service connection data
directly into your Spring Beans.
http://cloud.spring.io/spring-cloud-connectors/
spring-cloud-cloud-foundry-connector.html

142. Discover bound services &
deployment information at runtime.

143. Support for registering discovered
services as Spring beans.

144. New Relic, Cassandra, DB2,
MongoDB, MySQL, Oracle…

145. PostgreSQL, RabbitMQ, Redis,
SMTP, SQL Server, etc.

146. Cloud Foundry UAA.

147. OAuth 2 Server for
centralized ID management.

148. Supports Oauth, OpenID
Connect, SAML, LDAP, SCIM.

150. Single Sign On.

151. API security with OAuth.

152. User and group management.

153. JWT support.

154. Token revocation.

155. Database flexibility.

156. Auditing, logging, monitoring.

157. Spring Security and CF SSO.

158. Integrates to any ID Federation
via SAML/OpenID.

159. Converts complex SAML interactions
into basic OAuth tokens.