- Microservices Without the Servers (Amazon) — By “serverless,” we mean no explicit infrastructure required, as in: no servers, no deployments onto servers, no installed software of any kind. We’ll use only managed cloud services and a laptop. The diagram below illustrates the high-level components and their connections: a Lambda function as the compute (“backend”) and a mobile app that connects directly to it, plus Amazon API Gateway to provide an HTTP endpoint for a static Amazon S3-hosted website.
- Privacy vs Data Science — claims Apple is having trouble recruiting top-class machine learning talent because of the strict privacy-driven limits on data retention (Siri data: 6 months, Maps: 15 minutes). As a consequence, Apple’s smartphones attempt to crunch a great deal of user data locally rather than in the cloud.
- NAS Backdoors — firmware in some Seagate NAS drives is very vulnerable. It’s unclear whether these are Seagate-added, or came with third-party bundled software. Coming soon to lightbulbs, doors, thermostats, and all your favorite inanimate objects. (via BetaNews)
- Most Consumers Wouldn’t Pay Publishers What It Would Take to Replace Mobile Ad Income — they didn’t talk to this consumer.
Mapping the future of development by designing for distributed architectures.
With the advent of DevOps and various Platform-as-a-Service (PaaS) environments, many complex business requirements need to be met within a much shorter timeframe. The Internet of Things (IoT) is also changing how established applications and infrastructures are constructed. As a result of these converging trends, the enterprise IT landscape is becoming increasingly distributed, and the industry is starting to map how all the various components — from networking and middleware platforms, to ERP systems and microservices — will come together to create a new development paradigm that exists solely in the cloud.
A deep integration across design, development, and operations is critical to digital business success.
I just finished reading Thomas Wendt’s wonderful book, Design for Dasein. I recommend it to anyone who practices, or just is interested in, experience design. Wendt’s ideas have profound implications for rethinking and improving our approach to designing experiences. They also have profound implications for how we think about DevOps, and its relationship to design, and how that relationship impacts the nature and purpose of digital business.
Design for Dasein introduces what Wendt calls “phenomenological design thinking.” This is a new approach to design that expands the designer’s attention beyond creating things that people use, to encompass thinking about the ways in which things influence, interact with, and are influenced by how people experience the world. Phenomenological design thinking reflects two key insights about the role of designed objects in peoples’ lives. First, designers create possibilities for use rather than rigid solutions. Wendt cites the example of using an empty coke bottle to hold open a door in an old, crooked apartment. By itself, the bottle wasn’t heavy enough to keep the door from swinging shut, so he filled it with pennies. At that point, the bottle suddenly had three overlapping uses: containing and drinking soda, holding opening one’s bedroom door, and storing spare change. Wendt’s point is that the designer does not entirely control the object’s destiny. That destiny is co-created by the designer and the user.
Moving beyond ad-hoc automation to take advantage of patterns that deliver predictable capabilities.
Can you release new features to your customers every week? Every day? Every hour? Do new developers deploy code on their first day, or even during job interviews? Can you sleep soundly after a new hire’s deployment knowing your applications are all running perfectly fine? A rapid release cadence with the processes, tools, and culture that support the safe and reliable operation of cloud-native applications has become the key strategic factor for software-driven organizations who are shipping software faster with reduced risk. When you are able to release software more rapidly, you get a tighter feedback loop that allows you to respond more effectively to the needs of customers.
Continuous delivery is why software is becoming cloud-native: shipping software faster to reduce the time of your feedback loop. DevOps is how we approach the cultural and technical changes required to fully implement a cloud-native strategy. Microservices is the software architecture pattern used most successfully to expand your development and delivery operations and avoid slow, risky, monolithic deployment strategies. It’s difficult to succeed, for example, with a microservices strategy when you haven’t established a “fail fast” and “automate first” DevOps culture.
Continuous delivery, DevOps, and microservices describe the why, how, and what of being cloud-native. These competitive advantages are quickly becoming the ante to play the software game. In the most advanced expression of these concepts they are intertwined to the point of being inseparable. This is what it means to be cloud-native.
Designing, building, and operating services from the perspective of customer goals helps improve quality.
We often tend to think about “usability” as applying to a separate layer of digital service from functionality or operability. We treat it as a characteristic of an interface which intermediates between the user and an application’s utility. Operational concerns such as performance, resilience, or security are even further removed. This approach gets reflected in siloed design-development-operations practices. From the perspective of service quality, though, I think it may be more constructive to view usability as a characteristic of service as a whole.
What is service, anyway? In the language of service-dominant logic, it’s something that helps a customer accomplish a job-to-be-done. From that perspective, usability refers to the customer’s ability to ‘use’ the service to accomplish their goals. Everything that contributes to, or compromises, that ability, impacts usability.