From Zero to Production with Spring Boot and AWS

So far, there hasn't been.

This is a great idea, though, which is why decided to create a Slack community for Stratospheric, where you can discuss the book, ask questions, and work through the book together.

If you'd like to join the Slack community, please drop us a note.

Ultimately, because the three of us know Java very well. We wanted to express the deployment workflow in language we were already familiar with.

Furthermore, the book is about Spring Boot. Hence, it's only natural to use the same language and ecosystem, so as the reader you don't have to switch contexts.

Originally, we were going to use CloudFormation and the JSON or YAML configuration files that come with that. However, that approach turned out to be not particularly readable and maintainable.

AWS CDK has gained quite some traction and is starting to get more mature. Apart from Java, CDK is available for TypeScript and Python, too.

Absolutely.

That was the main idea behind the book and the perspective from which we wrote it.

No, it doesn't.

You probably couldn't write a book covering all of those. Instead, we decided to use and write about the most commonly useful services and use cases for generic web applications, such as SQL databases with RDS, key-value stores with DynamoDB, messaging with SQS and ActiveMQ, Cognito for registration and login, and SES for sending emails.

The general integration workflow is similar for other services, though, and the AWS Java SDK makes it convenient to use other services, too.

A lot of what we covered in the book is applicable to EKS / Kubernetes.

Everything except the Service CDK stack is independent of ECS. Besides, Docker can be used with EKS, too.

Yes, we do.

We're going to publish an online course, which will take segments from the book and present those in bite-sized pieces one can easily follow along.

We'll also continue to publish additional relevant content on our blogs (reflectoring.io, rieckpil.de, bjoernkw.com). So make sure to check those out every now and then, too.

Writing the book together worked very well.

As somewhat stereotypical software engineers, we like to mostly work by ourselves but also want to collaborate and regularly exchange ideas and feedback on our work.

We approached writing the book like a software development project:

• We had two-week sprints.
• We met every two weeks on Zoom.
• The process organically evolved into an agile process.
• We had a review process with pull requests for each finished chapter.

We also split up the other tasks associated with writing and publishing a book (e.g., marketing) among the three of us.

Self-publishing has been a real boon to us. There was no outside pressure but we had the intrinsic motivation to quickly and regularly provide value to our readers.

Probably too many to mention them all :-)

We expanded our own knowledge regarding developing software with and deploying applications on AWS. There are some pitfalls when working with AWS services in general and the CDK specifically, but overall, the self-service and infrastructure-as-code approach those enable are a huge step forward.

Collaboratively writing and self-publishing an eBook has been a tremendous experience, too. We learned a lot about writing, marketing, and polishing over the course of this process.

The AWS infrastructure spun up during the course of the book costs about 100 to 110 euros per month, depending on what you do and how often you deploy or recreate certain resources (e.g., the ActiveMQ WebSocket relay).

This might be a little too much for a pet project but seems alright for a small startup.

Unfortunately, not that we know of.

You can merely create alerts within the AWS Billing Console, which will ping you once a specified threshold has been reached. Those are just notifications, though. There's no simple service or feature that allows you to shut down resources automatically once costs exceed a certain level.

A possible approach to try out, though, might be an event triggering a Lambda function for executing CDK commands, which then destroy the infrastructure.

Where applicable (e.g., with Amazon RDS or Amazon MQ), we used the smallest possible instance types, because for demonstration purposes those were sufficient.

More generally, we set a monthly budget within the AWS Billing Console alongside an alert that notified use once a specific budget threshold had been reached.

We supply environment and application names for the chapter-specific versions of our sample Todo application, for example.

Where applicable and necessary, we use those to define namespaces. This allows to keep multiple versions of the application separate from each other and manage resources belonging to a specific version.

No, we haven't.

However, you can easily implement social logins with Amazon Cognito.

AWS not only is the largest and most widely used cloud provider, it also was the one we were most familiar with from client work and previous projects.

It only seemed natural to write about something we had already been using to some extent at least and for which we knew there was sizeable demand.

With Java being one of the major deployment targets for AWS and Spring/Spring Boot being well-supported through Spring Cloud, Spring Cloud AWS and the AWS Java SDK, ease-of-use and robust, reliable tooling probably are the major benefits of using Spring Boot in conjunction with AWS.

The book has been written entirely in Markua - Leanpub's Markdown flavor.

The book's layout is generated through Leanpub. For our writing process we made use of feature branches and pull requests reviews on GitHub.

When embarking on this project, we quickly arrived at $39 as an appropriate price point for what we envisioned, i.e., a comprehensive, from-start-to-finish guide for developing and deploying a Spring Boot application with AWS and the value such a book can provide to the reader.

With the initial release and the first few chapters in November 2020, we set the price to $20 and gradually increased the price from there with each subsequent release that contained additional content.

This approach - not unlike crowdfunding but with the added benefit of immediate value provided - allowed readers to support as early on, while it motivated us to publish at regular intervals and at a rapid pace to show we deserve that trust.

Yes, they do.

The combined use of AWS and Spring Boot is well-supported through Spring Cloud, Spring Cloud AWS and the AWS Java SDK.

Yes, absolutely.

We'll continue to write the occasional newsletter and also send updates via Leanpub whenever there's a new version of Stratospheric available.

Honestly, we have no idea :-)

This mostly depends on a specific reader's pace. Clocking in at about 450 pages and roughly 80,000 words, "Stratospheric - From Zero to Production with Spring Boot and AWS" isn't exactly a short book. You can certainly read the book from start to finish. We hope we've provided enough of a storyline and common thread for you to do so and follow along.

However, to a large extent, we designed both the three main parts and the chapters themselves to be modular. This allows you to pick out those sections and subjects that are most relevant to you at any given time.

First and foremost, our own work experience and previous client work has served as inspiration for working with this particular set of technologies.

From this previous experience knew there was significant demand but very little in the way of comprehensive guides or tutorials that not only help you with getting started with AWS and Spring Boot but really guide you all the way to a production-ready application and cloud deployment setup.

As outlined in the book's closing thoughts, the immediate next step is to start using cloud development and deployment options at your workplace or with your current - or next - SaaS side project.

Whether you're making decisions at your place of work or you're working in a larger team, we hope that Stratospheric has provided you with a conversation starter and arguments for adopting cloud development.

The table of contents is available both on this website and the Leanpub page for Stratospheric.

No, it isn't.

We probably could've written more tests but test coverage wasn't our primary focus while writing the book and the companion app.

If you'd like to delve more deeply into this subject you might want to take a look at the resources provided on Philip's website under "Testing Java Applications Made Simple".

Working with Leanpub has been a terrific experience.

Both the self-publishing approach in general and the integration with tools such as GitHub lent themselves to our writing process and the way we wanted to manage and publish our content. The idea of self-publishing in particular was what convinced us to use a service such as Leanpub.

The source code depends on AWS Java SDK v1 since we're currently still using Spring Cloud AWS 2.2.x, which in turn transitively depends on AWS Java SDK 1.x.

Yes, it will.

The book describes in detail how to deploy the resources and the relevant infrastructure used with AWS CDK.

Yes, it is.

The chapter about "Tracing User Actions with Amazon DynamoDB" covers DynamoDB in great detail.

For the user interface we used Thymeleaf. Additionally, we used these libraries and frameworks:

• Thymeleaf Layout Dialect (for reusable templates)
• Bootstrap (for layout and a common UI look & feel)
• SockJS & STOMP.js (for push notifications)
• WebJars (for web frontend dependencies)

As of today (August 8th, 2021), there isn't, unfortunately.

See this GitHub issue for possible future updates. According to the CDK documentation "it is possible to write AWS CDK applications in JVM-hosted languages other than Java". However, AWS doesn't provide any support for that.

Yes, it is.

The chapters on "The Sample Todo Application", "Building User Registration and Login with Cognito", "Sharing Todos with SQS and SES", and "Metrics with Amazon CloudWatch" specifically make us of Spring Cloud AWS.