It often surprises other devs when I suggest that Spring Boot is a perfect addition to the IoT developer’s toolbox. If you’re deep into IoT and have the luxury of another group providing all of your back-end and/or cloud platform code, that’s perfectly understandable. However, if you’re a full-stack developer, by choice or necessity, you need to know this! Grab a chair and a cup of coffee; I think you’ll find this interesting (and useful).

Let Me Just Put This Out There

Here is what most people imagine when they hear “IoT”:

Internet of THINGS

But this is what they should be thinking:

INTERNET of Things

The things get most of the attention, mindshare, and “buzz”. Why is that? Well…because gadgets are cool! Most of us chose to be developers because of the fun/interesting/obsessive parts, not because of the dull bits. And while there are usually fun and (ahem) less-fun components to everything, who can resist gadgetry in general?

Ah, but without connectivity, without storage, without the ability to monitor, manage, and analyze those often-remote sensors and controls…what do we have? Truthfully, not much. Something interesting, but barely so; a school science project, perhaps. The real payoff (in money and intrigue) is in what happens when you connect those “things”. Without a versatile and reliable platform behind those devices, you just have islands of misfit toys.

This is where Spring Boot really shines: helping you to create meaningful software at velocity. Software that is clean, concise, readable, maintainable…and built Cloud Native. We’ll come back to that last part over the next few installments, but for now, let’s focus upon building a basic platform to enable your IoT to mean something.

Choose Your Legos(TM)

Spring Boot integrates several useful capabilities into a single, coherent code framework and approach. In a nutshell, it helps a developer rapidly build stand-alone applications that incorporate and integrate with various third-party libraries that can be deployed anywhere a JAR will run. Anywhere. It’s open source, opinionated (minimal configuration, but flexible to fully accommodate edge cases), and insanely effective. Coming from a more staid environment, I found my first exposure to Spring Boot (and every one since) surprising and refreshing. If so-called enterprise software development sounds boring to you, you probably haven’t taken Boot for a test drive.

And that’s it! Kidding, that’s not it. But Spring Boot does bring along several goodies that streamline the effort it takes to build robust back end applications. Remember how I said it’s “opinionated”? Let’s examine a few of its carefully-chosen opinions, step through building a simple cloud-ready application for your IoT system, and then see where that takes us. Shall we?

On Your Mark, Get Set, Go!

The Spring Initializr gets our project off to a running start. There are several ways to accomplish this, but since we’re taking the simplest path possible for this first example, let’s just point our browsers to start.spring.io. Spring Boot gives you options, such as a Gradle-based build, various versions of Boot, Java/Groovy, and packaging (JAR vs. WAR), but we’ll stick to most of the defaults for our example.

NOTE: To see all of the choices at your disposal, simply click the “Switch to the full version.” link at the bottom of the page.

Here are the choices we’ll make for our example:

• Maven Project
• Latest non-snapshot version of Spring Boot
• Group: org.thehecklers (feel free to use your own)
• Artifact: iot-service
• Dependencies: Web, JPA*, H2**, REST Repositories

* For this example, we’ll use a JPA data source, but feel free to choose a NoSQL option. Boot gives you many data source options out of the box, and of course, you can “bring your own” with a bit more effort.
** H2 is an in-memory database. While unsuitable for environments in which physical persistence is a requirement, it functions the same from a developer perspective and satisfies our demo requirements nicely for now.

Once we’ve made the above selections, simply click the Generate Project button to have the Spring Initializr generate a skeleton project, bundle it into a .zip file, and serve it up for download. Save it locally, unzip it, and open the project in your favorite IDE to get started coding.

Building your IoT Service

With just that little bit of effort, we already have the foundation in place for our IoT back end service. You can verify this by running the app and pointing your browser to localhost:8080. You should see the following:

“Large streams from little fountains flow, Tall oaks from little acorns grow.”

For this installment, we’ll focus on the MVP (Minimum Viable Product) needed to support our nascent IoT installation. Assuming we’ll need to track readings captured by one or more sensors, let’s define an Entity class for our Readings:

The annotations @Entity, @Id, and @GeneratedValue are from the Java Persistence API (JPA) standard and identify/describe the class and its Id attribute as a JPA entity and its primary key, respectively. Aside from these annotations, the Reading class is just a straightforward POJO.

Next, we face the daunting task of creating the following functionality:

• REST endpoint(s) via which our devices can provide (POST) readings
• REST endpoint(s) allowing us to retrieve (GET) readings for review, reporting, and analysis
• Mechanism(s) for storage and retrieval of readings from our chosen data store

Spring makes this functionality easy to implement. Spring Data REST was one of the dependencies we included when we created this project (REST Repositories), and by simply extending a Spring Data repository interface specifying the Reading class and Id type and annotating our new interface as a RepositoryRestResource, the repository is exposed via a REST API. For now, this meets our needs nicely:

Re-running our application and refreshing our browser page (localhost:8080) confirms that our REST endpoint for readings is now active:

Getting there…

Next, let’s test functionality by emulating a device pushing readings to our IoT service. I used curl, but feel free to use whatever means you prefer to POST to a REST endpoint.

Then we verify using a vanilla curl GET:

Here we see the two readings I created in testing, returned via our GET request:

If you’ve been pair-programming with me, congratulations! You have now created your first very basic IoT service…and since we had Spring Boot build a fully self-contained “uberJAR” (bringing its own container with it), it can be deployed wherever Java is installed. Who would have thought it could be this fast (or fun)?!?

Future Articles, Future Enhancements

As we proceed, there are several topics we will expand upon, options/adjustments we will explore (WebSocket, SQL & NoSQL persistence, …), functionality we can add (security, tailored queries, visualizations, …), and of course, we’ll leverage Spring Boot’s focus upon Cloud Native Java to deploy quickly and easily to the leading open source cloud platform, Cloud Foundry. If you have comments, questions, or suggestions, please leave them below! For updates, please follow me on Twitter at @MkHeck.

Keep coding,
Mark

Additional Information

Spring Initializr
Spring Boot
Spring Data REST
Spring Getting Started Guides
Cloud Foundry
Pivotal Cloud Foundry
Pivotal Web Services (for free trial)

Related Posts:

• Building a Portable, Self-powering, Cloud-Connected IoT demo
• Nighthacking Interview: Jfokus
• T4SD (Tips 4 Spring Devs): How to get Spring Boot REST endpoints to speak XML
• How to Create an Alexa Skill with Spring Boot & Cloud Foundry
• Getting up & running quickly with Spring Cloud Sleuth

At JavaOne last week, several people asked me how my work at Pivotal was going, and it occurred to me: I had been so busy diving into all the new toys that I hadn’t written anything about it! This is a first step toward remedying that.  🙂

At the risk of this post sounding like a short commercial, I’m deeply impressed with the consistency of vision and the depth and breadth of capabilities Pivotal offers innovative organizations and developers. The various Spring offerings solve real problems, and they solve them in ways that are “developer first”…ways that make sense not just conceptually, but also when pounding out code in an IDE (or vi/emacs, if you prefer). You hear a lot about an “opinionated” approach, and that could be chafing if there weren’t such flexibility to do it it your way anytime needed/desired; but the goal is always the same:

Offer a way to get things done cleanly and easily by following a prescribed (opinionated) approach…

…but get out of the way quickly when another approach is warranted/desired.

Best of both worlds.

With regard to Pivotal Cloud Foundry…I once heard it described as the “travel adapter” of cloud services, and that explanation is brilliant. In short, Pivotal Cloud Foundry (PCF):

• Works with a variety of underlying infrastructures (VMware, OpenStack, Amazon, Azure, Google Cloud)
• Runs on-premises or public
• Provides a single, elegant API for developers, regardless of infrastructure
• Provides a single, elegant API for developers, regardless of siting (on-premises or public cloud)
• Provides a true Cloud Native platform: drag, drop, run

If you’ve used other cloud platforms (and not yet used Pivotal Cloud Foundry), you’re probably reading and re-reading that list with some combination of skepticism and guarded envy. Don’t believe me; believe yourself: sign up for a free 60-day trial here and kick the tires. No better way to see the future than to create a small Spring Boot application (or bring your own) and deploy it to PCF. You’ll wonder why other vendors make it so difficult when it can be so straightforward.

In summary, I’m working on a great team in a great company with products from the future. What’s not to love? 😀

Cheers,
Mark

For everyone I met and re-met (!) at JavaOne, thank you for your friendship and commitment to this great community! Looking forward to our paths crossing again, and looking forward to meeting new “old friends” soon.

Please check back here (or follow me on Twitter: @MkHeck) for periodic ponderances, quick tips, and everything in between. Keep that code flowing!

Related Posts:

• Please check back for related posts!

pivotal:

1. Of, relating to, or serving as a pivot.
2. Being of vital or central importance; crucial.

As has been widely reported, last week I was among those at Oracle who were “let go” – a sanitized expression that is meant to diminish the indescribable impact of being fired due to circumstances far outside one’s knowledge or ability to influence. Details aren’t important, but suffice it to say that my teammates and I were…surprised. 🙂

The Java community is so much more than one company. It is many companies, organizations, not-for-profits, JUGs, individuals…so many who make it the vibrant, sharing community we all love. I’ve spoken with several, and I’ve had some wonderful conversations with organizations with a vision. This community is very much alive, and great ideas are flowing, with more on tap!

Pivotal

Which brings me to some exciting news! I’ll soon be joining the team at Pivotal. I won’t name names, as there are simply too many outstanding colleagues to mention without inadvertently leaving someone out. But you know them: they’re thinkers, innovators, and doers. Pivotal has some great tools in their toolbox, and I can’t wait to put every one of them to good use! I feel like a kid in a candy store. 🙂

I still have some good friends and colleagues within Oracle, and I respect them deeply for doing amazing things with Java and the community. They are awesome, and those individuals deserve your support. But this is a pivotal (you knew that pun was coming, didn’t you?!?!) moment for me, and I look forward to some pretty amazing things moving forward!

Whether you’re an old friend or new, or a soon-to-be one, if you happen to be at a conference where I am, please catch up with me and say “Hi”. I’m looking forward to it. 🙂

Onward & upward,
Mark

Follow me on Twitter (@MkHeck) for updates as the journey unfolds!

Related Posts:

• Please check back for related posts!

When I got my first Raspberry Pi Model B (not long after they first became available – remember when they only had 256M?!?), I wanted to configure it to use a wifi adapter. Even with approved, compliant adapters, this wasn’t for the faint of heart; many steps, scripts, and secret incantations were required to get everything to connect, even in the best of circumstances.

Fast-forward to today, when wifi adapter drivers are included in the base Raspbian build. It’s relatively simple to connect to wifi networks that broadcast their SSIDs. Ah, but what about those with hidden SSIDs? Not so much.

Many sites have documented ways to get around this. The problem is that I’ve tried several of them without success, so I always return to my original settings – and they still work just as well as the day I put them together. So to save myself (and hopefully you, if you’re reading this post!) a great deal of time in the future, here is the shortest path I’ve found to configuring your Raspbian-running Pi to connect to a wifi network that doesn’t broadcast its SSID.

The Secret Sauce Steps

0. Log into your Pi (default user ID: pi, default password: raspberry).

Edit the network interfaces file

1. cd /etc/network

2. sudo cp interfaces interfaces.orig (this makes a backup copy of your interfaces file)

3. sudo vi interfaces (feel free to use a different editor if vi isn’t your cup of tea)

4. Edit your interfaces file to look like this:

5. Save the interfaces file.

Edit wpa_supplicant

1. cd /etc/wpa_supplicant

2. sudo cp wpa_supplicant.conf wpa_supplicant.conf.orig

3. sudo vi wpa_supplicant.conf

4. Edit your wpa_supplicant file to look like this:

5. Save the wpa_supplicant.conf file.

NOTE: If you have another network entry in this file (e.g. for a guest network), be sure to place this line in its entry to prevent its use:

Test

• sudo reboot
• Login once prompted.
• ifconfig -a

If it’s working properly, your wlan0 adapter will show a valid IP address, a number of bytes and packets received and sent (RX and TX), and several other useful bits of information.

That’s all, folks

I’ve used this with three different wifi adapters, and it’s worked every time. Hopefully, it will work for you as well.

If you found this useful (or not, clear or confusing, etc.), please let me know. Good luck, and enjoy your Pi!

Keep coding,
Mark

Related Posts:

• Building a Portable, Self-powering, Cloud-Connected IoT demo
• Quick & Dirty How-to Guide: Install GlassFish 4 on Raspberry Pi
• Adding Solar/PV to A MANAGEABLE Renewable Energy System

Intro

I started this post a couple months ago, and between a busy holiday season and constant revisions, I’m only now polishing and posting it. For those who knew it was in the pipeline, thank you for your patience. 🙂

I have another article in the works that will delve into more technical aspects of the microservices discussion; hopefully I’ll get that posted by this time next year (!). In this one, though, I’d like to stay as much as possible at the conceptual level, dipping into the details only to reference them for consideration and future discussion. No guarantees, but that’s the plan. 🙂

Discussion

First, a good-natured poke at our discipline in general…

The Holy Grail of Software Development

Regardless of the new architecture, technique, methodology, framework, language/feature, etc., we (as developers) often fall prey to the temptation to make it a “one size fits all” solution. Regardless of the problem at hand, we break out our new toy, er, tool and apply it vigorously, without the benefit of objective consideration of suitability to the task at hand. To paraphrase two Abrahams (Kaplan and Maslow) the way I’ve always heard it:

“To the man with a hammer, everything looks like a nail.”

This doesn’t have anything to do with microservices directly…only with the fawning attitude for the concept that seems to be prevalent at the moment. 🙂

Along those same lines, I’d like to issue a couple of disclaimers here. I work for Oracle, so my experiences and worldview may differ from yours. That said, I like to think of myself as a fairly fact-based being; while I have been wrong many times and shall be again (many times), I do my best to analyze and come to conclusions based upon objective measures and reasoned assessments. Really, I do.

Secondly, it is incredibly difficult to make statements about microservices or anything else within the dev sphere that are 100% accurate and/or conclusive. I’ve tried to avoid blanket generalizations, but frankly, it’s nearly impossible to discuss anything without making some sweeping statements that one assumes/hopes will be understood as they were intended. If something below puzzles you or doesn’t sound right, please drop me a line and ask.

And finally, the views expressed in this post are mine and don’t represent those of Oracle. Or maybe anyone else. They’re just mine. 🙂

Now, back to microservices!

As with any tool applied indiscriminately to all problems, fit is often imperfect. Let’s take a closer look at what microservices are, what they’re up against, and their particular strengths and weaknesses.

Definitions

Microservices

“…the microservice architectural style…is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
Martin Fowler

Let’s dissect this a bit.

“…the microservice architectural style…is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

This is a good start. Without going overboard trying to explain something that is fairly straightforward, we’re talking about breaking down a large, complex application into small(ish – we’ll get to that a bit later) services that are more granular. Doing so should enable us to focus upon a more specific outcome for each portion of the overall functionality, which should result in better component manageability and quality.

“These services are built around business capabilities and independently deployable by fully automated deployment machinery.”

With all respect to Mr. Fowler, this bit of text is not specific to microservices. Capability-driven development approaches are used in many different contexts, and automated deployment is even less useful as a differentiator. For this discussion, we’ll ignore this bit of text entirely.

“There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

Unlike the previous statement, this is a very useful description of microservices that, while not entirely unique to them, lays out two key tenets:

• Microservices are decentralized. They could be hosted anywhere.
• Microservices are heterogeneous. They can be written in the developers’ language of choice and deployed on their platform of choice, as long as the “connections” are properly made.

The “Alternative(s)”

Everything else, of course. 🙂

The microservices concept primarily addresses the server side of the equation; the client component is a player only insofar as it is involved in the delivery of the application’s functionality. In the strictest sense, microservices focus upon the delivery of capabilities via (micro)services provided by server(s).

Keeping that same specific focus, the alternative is really the “monolithic” application, typically delivered as a single unit containing all functionality for the entire set of targeted use cases. Some means of delivering so-called monolithic applications include (but are not limited to) Java EE, .NET, or any other server-side environment that provides functionality to the user via an application server or an affiliated cluster of app servers.

Pros of a Microservices Architecture

Manageability

Firstly, anyone who has struggled under the weight of a large server-based application can immediately see the appeal of microservices. Monolithic apps can get “too big”, becoming unwieldy to develop and maintain. With so much complexity in a single code base, it becomes difficult to test, debug, etc. without the law of unintended consequences wreaking havoc in novel ways.

Extensibility

With a microservices architecture, functionality can be “farmed out” and provided by others, often developers/teams who don’t even work for your organization. While this isn’t unique to microservices, the architecture certainly facilitates it; creating and documenting the interfaces within the core app to support various connection points makes developing and integrating external functionality far easier for those outside the core application’s dev team than any monolithic app could be.

Location/Scalability

This also allows hosted functionality to be geographically dispersed more readily than typical alternatives, deploying microservices wherever it makes sense to do so (using any criteria). If a development partner on one side of the world decided to provide a microservice that integrates with a core application hosted on the other, this could be done easily by complying with published interface standards and requirements. Adding an external functionality provider is far less disruptive to the core app if it was designed with that end in mind, and that is the core principle of a microservice architecture (see above).

Granularity

Creating an application with microservices in mind also can result in a leaner core application. It’s an imperfect analogy, but composition vs. inheritance applies here. If your architecture embraces the creation of a core set of functionality with numerous extension points, your core app potentially can be more focused and functionally cohesive…as can each microservice.

Cons of a Microservices Architecture

Any architectural decision has its downside, and a microservices architecture creates new challenges while it’s solving old ones. Here are a few potential hurdles that microservices face.

Control

If you thought debugging and testing a monolithic application was a challenge – with all code directly accessible and modifiable (to varying extents) from the comfort of your IDE – you’re probably cringing at the thought of your pending inability to sink your hands into the entire codebase to fix bugs that surface or (more) easily test and diagnose aberrant behavior that is reported in your app. End-users will not know (and won’t care) that something breaks due to a partner’s error in implementing an interface, failure to completely debug an edge case, or even an innovative misuse of the app by said user. Your app is broken, #fail.

Consistency

If portions of your application’s functionality are provided by other groups or organizations, maintaining consistency becomes more difficult. User interfaces, error handling, text phrasing…these are just a few examples of areas where small differences can make a huge impact on the overall user experience.

Overhead

Say what you will about about monolithic apps, but infrastructure and interfaces are costs that are borne once for the entire (monolithic) application…to say nothing of transactions. When portions of your app’s functionality are provided via microservices hosted on various external platforms, connection security and authentication/authorization must be factored into the most insignificant internal interactions. It’s only a bit of an exaggeration to say that with a microservices architecture, there are no local interfaces. And for those who think “microservices” means “tiny services”, there is no limit to the size/scope of a so-called microservice. Factoring in the overhead, they can involve more code than you might expect, somewhat negating some of the advantages of “leanness” you may have been anticipating.

Fragility

With multiple infrastructures and databases potentially hosted on various platforms in far-flung places, a microservices-based application certainly offers more breakpoints. At best, this introduces latency concerns; at worst, fragility. If any key bits of functionality are delivered via an (external) microservice, the unavailability of that microservice breaks your app. This is less of a concern if the group supporting the failed service is just down the hallway; but if the other organization is in a different building, city, or country, small breakages can quickly result in painful outages and even lost customers. See the note about Control above.

In Conclusion (For Now)

A microservices architecture offers another viable approach, another option to deliver more functionality to end-users…but it is not a silver bullet.

A microservices architecture can provide greater flexibility and code quality by capability at the possible expense of (overall) application availability and control. It’s a great tool, used wisely and in the right circumstances…but as with any great tool, it doesn’t remove the responsibility to think prior to (and while) employing it.

Now, go develop something. 🙂

Cheers,
Mark

Related Posts:

• Join Us at JavaOne 2014!
• Thanks For Sharing Informal International HackFest – A Virtual Event!
• Quick & Dirty How-to Guide: Install GlassFish 4 on Raspberry Pi
• HackFest – Postponed!
• HackFest – Thanks For Sharing!