How SparkPost Views Microservices
How SparkPost Views Microservices
Microservices make it easier for SparkPost to update and deploy their email delivery services to developers and enterprises.
Join the DZone community and get the full member experience.Join For Free
Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.
How is your company involved in the creation or use of microservices?
We are an email delivery service for developers and enterprises. We are primarily an API company, though we also have a UI for configuration and reporting. Besides the core messaging engine under the hood, we build much of the SparkPost API using microservices.
What do you see as the most important benefits of microservices?
Faster development and iteration. Easier to maintain and refactor. Easier to control. Fewer dependencies across teams (we run six), automated test suites, less coordination required, an API first approach (all well documented with good client libraries), and a governance group that includes tech and product leads from different teams.
Which programming languages, frameworks, and tools do you, or your company use, to build out microservices?
Our “go to” language for microservices is NodeJS, often using the ExpressJS library. We use NGINX as a proxy, which helps stitch, multiple microservices into a single endpoint where we can also perform authentication. All code is on GitHub. We use Bamboo for CI/CD pipeline orchestration, along with Ansible for configuration and deployment.
How have microservices changed application development?
It has made it easier to onboard new developers. There is also less overhead for deployments. We also have the ability to shape individual services based on changing technology and business needs.
What kind of security techniques and tools do you find most effective for securing microservices?
There are no silver bullets to security with microservices. At SparkPost, we take a layered approach, which includes coding standards, peer reviews, automated testing, and third-party pen testing. In some ways, you also get a more secure public profile with APIs.
What are some real-world problems you, or your clients, are solving with microservices?
We built a powerful email performance metrics microservice API. Backed by a powerful analytics database the API support time-series reporting and ad-hoc aggregation and filtering by different attributes and time ranges. We also provide an event log service to access the raw data. People love our reporting capabilities in both the API and UI and the fact they can access the raw event data. Using microservices has made it easier to iterate and add new features.
What are the most common issues you see affecting the implementation of microservices?
API conventions and standards can vary widely which makes integration challenging. Come up with your own conventions for what you want to do, document them and be sure to apply across teams. Evolve to mix and match conventions that are right for your business. At a minimum, Microservices should be RESTful and use JSON. Understand the versioning strategy that is right for you and ensures everyone is on the same page. Avoid letting versioning be the tail that wags the dog – consider going versionless.
Do you have any concerns regarding the current state of microservices?
There is no “one size fits all.” Many languages, tools, and API gateways. Don’t get locked into one way of doing things you always have alternatives.
What’s the future for microservices from your point of view - where do the greatest opportunities lie?
Microservices implemented as functions-as-a-service, otherwise known as “serverless”. Besides serverless, expect to see continued use of containers or a combination of the two approaches.
What do developers need to keep in mind when working on microservices?
If a Microservices is too big it can slow you down. However, being too small can result in unnecessary interdependencies. Don’t get hung up on size - be willing to split, combine, or otherwise refactor as your needs change. Have a strategy for converting monolithic applications to microservices. Look at what others have done. There’s no need to create a completely new methodology – leverage all the great knowledge and best practices already available.
Is there anything you’d like to know about what software developers are doing with regards to microservices?
What kind of API gateways or proxies are they using? What is their uptake of other tools? What are they doing to address such things as rate limiting and authentication?
Opinions expressed by DZone contributors are their own.