|
Because you are an InfoQ newsletter subscriber, we’re delighted to be able to share our first monthly architect’s newsletter with you, which we will send on the last Friday of every month. If you do not want to receive it in future, unsubscribe.
The role of a modern software architect is continually shifting. Gone are the days where the architect title was a position earned purely by seniority - the range of topics and the velocity at which they change within the software development industry means that continual research, learning and experimentation with new technologies is now vital for success in this role. InfoQ strives to facilitate the spread of knowledge and innovation within this space, but we acknowledge that it can be difficult for a busy architect to digest all of the content being produced. Accordingly we have created this newsletter, written by a team actively involved with the architecture and delivery of real-world software applications.
We aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We will strive to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices.
News
Streaming Microservices: Contracts & Compatibility
In a world of microservices that communicate via unbounded streams of events, schemas are the contracts between the services. Having an agreed contract allows the teams developing those services to move fast, by reducing the risk involved in making changes. At QCon New York, Gwen Shapira discussed the challenges of compatibility, and introduced possible solutions to manage this, such as a centralised schema registry, which stores a versioned history of all schemas, provides multiple compatibility settings and allows evolution of schemas according to the configured compatibility setting.
An open source realisation of this pattern is the Confluent Schema Registry, which provides serializers that plug into Kafka clients that handle schema storage and retrieval for Kafka messages that are sent in the Avro format.
The Difference between SOA and Microservices?
There have been several articles over the past five years on the differences and similarities between SOA and microservices. Some suggest there is much to be learned from SOA whereas others believe that distancing microservices from SOA is more beneficial. Furthermore, Neal Ford, amongst others, has suggested that moving from monolithic architectures to a services-based approach may be easier than going to microservices. There has not been much activity recently around the overall "SOA or microservices" debate until RedMonk's Stephen O'Grady published an article on the subject. O'Grady suggests that using only size for defining microservices is a poor measure, and ultimately useless for determining whether a service has the right responsibilities - and this should be the key driver when defining a microservices architecture.
The Paved PaaS to Microservices at Netflix
At QCon New York 2017, Yunong Xiao presented "The Paved PaaS to Microservices at Netflix" which discussed how the Netflix Platform as a Service (PaaS) assists with maintaining the balance between the culture of freedom and responsibility and the overall organisational goals of velocity and reliability. The Netflix PaaS team attempts to provide a sensibly configured but customisable "paved road" platform for developers by offering standardised and compatible components, pre-assembling the platform, and by providing extensive automation and tooling.
Applications are deployed to the PaaS using a typical workflow of development, testing (using Jenkins), deployment (via Spinnaker) and operations. The platform provides a CLI for common development tasks, such as environment bootstrap, integration with continuous delivery tooling, and running locally and in the cloud. In addition to the testing support provided by the continuous delivery pipelines, the platform also provides first class mocks that allow a developer to test against functionality provided by the platform and simulate and stub required responses.
Case Studies: Migrating to Microservices
The Microservices Journey from a Startup Perspective
Microservices come with complexities like multiple independent services, operational & communication complexity, partitioned data, and the complexity of eventual consistency. Susanne Kaiser, CTO at Just Software, spoke at QCon New York 2017 about the transformation process her team went through to transition from a monolithic application architecture to microservices model.
Kaiser’s key learnings included: not having an explicit infrastructure team will slow down the migration; decomposing big chunks of system functionality upfront is not recommended; and be prepared for the transition to a new way of building software to take longer than originally anticipated.
Managing Data with a Microservice Migration
Microservices architectures are evolutionary, and organizations like eBay, Twitter, and Amazon have all gone through several architecture iterations in the transition from monolithic applications to microservices. Factors to consider when designing a microservice-based architecture include each service having a single purpose, a well defined interface, and being modular and independent. Each microservice should also be responsible for isolated persistence. Randy Shoup, VP Engineering at Stitch Fix, spoke at QCon New York 2017 about managing the data and isolated persistence in microservices based applications.
Extracting microservices from a monolithic shared database involves the following steps:
- Create a service: The service boundaries should include the service itself and the database it fronts.
- Applications use the service: Decouple the apps from the shared database by using the newly created service.
- Move data to private database: Then move the data from the shared database to a new private database. No impact on the client apps because they no longer directly depend on the database.
- Repeat: Follow the same process for other business functions in the application that need to be their own microservices.
|
This eBook provides advice from 10 SecDevOps leaders on how to bake security into DevOps practices rather than treating it as an afterthought.
Learn how your organization can benefit.
Sponsored content
|
|
|
Secure Microservices Adoption
Moving to a microservice architecture enables the ability to isolate domains at a granular level, and also decentralise data management. This in turn can allow the prioritisation and handling of risk management for each individual service. At the microXchg conference Grygoriy Gonchar discussed “Secure Microservices Adoption”, and provided the following takeaways: the Backend-for-Frontend (BFF) pattern can delegate authentication and encapsulate roles complexity from downstream services; the use of mutual TLS certificates can provide service-to-service trust; embracing distributed systems principles and introducing new technologies can introduce new risks that developers will be unfamiliar with; and secure microservices adoption requires automation to mitigate new risks (e.g. deployment artefact threat scanning, secrets management, and vulnerability assessment).
QCon Chair Wes Reisz also recently sat down with Sam Newman and discussed “Security Considerations and the State of Microservices” in the InfoQ Podcast. Key takeaways included: different organisations have different risk appetites for new technology - what may be appropriate for one organisation may not be appropriate technology choices for another; organisations should be clear as to the benefits and challenges of adopting microservices for their context; using a cryptographic token that is verifiable offline is a common pattern for passing authentication contexts around to different services; and serverless architectures reduce the need to monitor server patching, but does not diminish the need for monitoring application runtime or library dependencies from security patching.
To keep up-to-date with everything InfoQ is publishing on Microservices, follow the topic on InfoQ
This is the first issue of a monthly newsletter, focusing exclusively on software architecture. We thought it would be valuable for you to get a quick overview of things you should keep an eye on. If this is not the case, you can unsubscribe using the link below.
Forwarded email? Subscribe and get your own copy.
|
