- The Mortality of Companies — Geoffrey West paper: we show that the mortality of publicly traded companies manifests an approximately constant hazard rate over long periods of observation. This regularity indicates that mortality rates are independent of a company’s age. We show that the typical half-life of a publicly traded company is about a decade, regardless of business sector.
- The Fortune 500 Teller — profile of Geoffrey West. (via Roger Dennis)
- Gizmo — a microservice toolkit in Golang from NYT. (via InfoQ)
- Intellectual Need and Problem-Free Activity in the Mathematics Classroom (PDF) — Although this is not an empirical study, we use data from observed high school algebra classrooms to illustrate four categories of activity students engage in while feeling little or no intellectual need. We present multiple examples for each category in order to draw out different nuances of the activity, and we contrast the observed situations with ones that would provide various types of intellectual need. Finally, we offer general suggestions for teaching with intellectual need.
"microservices" entries
Four short links: 25 January 2016
Company Mortality, Geoffrey West Profile, Microservice Toolkit, and Problem-Free Activities
Four short links: 2 December 2015
Regulating Addictive Attention, Microservice Middleware, Better 3D Scanning, and Anti-Disassembly Tricks
- If the Internet is Addictive, Why Don’t We Regulate It? — an excellent look at behaviourism, gambling machine flow, design-for-addiction, attention, regulation. As Schüll puts it: ‘It just seems very duplicitous to design with the goal of capturing attention, and then to put the whole burden onto the individual.’
- Zipnish — using varnish as middleware for your microservices, with Zipnish to create Zipkin-style analysis of your API performance.
- Using Polarisation to Improve 3D Scanning (PDF) — The proposed technique can resolve finer detail than some laser scannners
- Anti-Disassembly Tricks Used in Malware — also “things I remember from trying to break copy protection in 1980s games.”
Four short links: 5 November 2015
Robotic Delivery, Materials Science, Open Source Project Management, and Open Source Secret Management
- Starship — robotic delivery, from Skype co-founders. Pilot in the U.K. next year, in U.S. the year after. (via Brad Templeton)
- Materials that Couple Sensing, Actuation, Computation, and Communication (PDF) — very readable rundown of the ways in which materials can be designed to sense, compute, actuate, and communicate. You should read this because if the Internet of Things is going to be big, then the real breakthroughs and leaps forward will be in the Things and not the Internet. (via CCC Blog)
- Taiga — open source agile software project management tool (backlog, kanban, tasks, sprints, burndown charts, that sort of thing). (via Jef Vratny)
- Confidant — a secret management system, for AWS, from Lyft. If you build services that need to talk to each other, it quickly gets difficult to distribute and manage permissions to those services. So, naturally, the solution is to add another service. (In accordance with the Fundamental Theorem of Computer Science.)
Boost your career with new levels of automation
Elevate automation through orchestration.
As sysadmins we have been responsible for running applications for decades. We have done everything to meet demanding SLAs including “automating all the things” and even trading sleep cycles to recuse applications from production fires. While we have earned many battle scars and can step back and admire fully automated deployment pipelines, it feels like there has always been something missing. Our infrastructure still feels like an accident waiting to happen and somehow, no matter how much we manage to automate, the expense of infrastructure continues to increase.
The root of this feeling comes from the fact that many of our tools don’t provide the proper insight into what’s really going on and require us to reverse engineer applications in order to effectively monitor them and recover from failures. Today many people bolt on monitoring solutions that attempt to probe applications from the outside and report “health” status to a centralized monitoring system, which seems to be riddled with false alarms or a list of alarms that are not worth looking into because there is no clear path to resolution.
What makes this worse is how we typically handle common failure scenarios such as node failures. Today many of us are forced to statically assign applications to machines and manage resource allocations on a spreadsheet. It’s very common to assign a single application to a VM to avoid dependency conflicts and ensure proper resource allocations. Many of the tools in our tool belt have be optimized for this pattern and the results are less than optimal. Sure this is better than doing it manually, but current methods are resulting in low resource utilization, which means our EC2 bills continue to increase — because the more you automate, the more things people want to do.
How do we reverse course on this situation? Read more…
Four short links: 25 August 2015
Microservices Anti-Patterns, Reverse Engineering Course, Graph Language, and Automation Research
- Seven Microservices Anti-Patterns — One common mistake people made with SOA was misunderstanding how to achieve the reusability of services. Teams mostly focused on technical cohesion rather than functional regarding reusability. For example, several services functioned as a data access layer (ORM) to expose tables as services; they thought it would be highly reusable. This created an artificial physical layer managed by a horizontal team, which caused delivery dependency. Any service created should be highly autonomous – meaning independent of each other.
- CSCI 4974 / 6974 Hardware Reverse Engineering — RPI CS course in reverse engineering.
- The Gremlin Graph Traversal Language (Slideshare) — preso on a language for navigating graph data structures, which is part of the Apache TinkerPop (“Open Source Graph Computing”) suite.
- Why Are There Still So Many Jobs? The History and Future of Workplace Automation (PDF) — paper about the history of technology and labour. The issue is not that middle-class workers are doomed by automation and technology, but instead that human capital investment must be at the heart of any long-term strategy for producing skills that are complemented by rather than substituted for by technological change. Found via Scott Santens’s comprehensive rebuttal.
The cloud-native future
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.
Four short links: 9 April 2015
Robot Personalities, Programmer Competency, Docker Dependencies, and Large Files in Git
- Google’s Patent on Virtual People Personalities — via IEEE Spectrum, who are not bullish, a method for downloadable personalities. Prior art? Don’t talk to me about prior art. The only thing more depressing than this patent is the tech commentary that fails to cite Hitchhiker’s Guide to the Galaxy.
- Programmer Competency Matrix — a rubric for developer development.
- Aviator — Clever’s open source service dependency management tool, described here.
- Announcing Git’s Large File Storage — an improved way to integrate large binary files such as audio samples, data sets, graphics, and videos into your Git workflow..
4 reasons why microservices resonate
Microservices optimize evolutionary change at a granular level.
We just finished the first O’Reilly Software Architecture Conference and the overwhelming most popular topic was microservices. Why all the hype about an architectural style?
Microservices are the first post-DevOps revolution architecture.
The DevOps revolution highlighted how much inadvertent friction an outdated operations mindset can cause, starting the move towards automating away manual tasks. By automating chores like machine provisioning and deployments, it suddenly became cheap to make changes that used to be expensive. Some architects properly viewed this new capability as a super power, and built architectures that fully embraced the operational aspects of their design. The Microservice architectural style prioritizes operational concerns as one of the key aspects of the architecture.
Microservice architectures borrow a design aesthetic from Domain Driven Design called the Bounded Context. A bounded context encapsulates all internal details of that domain and has explicit integration points with other bounded contexts. Microservice architectures reify the logical DDD bounded context into physical architecture. For example, it is common in microservice architectures for services that must persist data to own their database: members of the service team handle provisioning, backups, schema, migration, etc. In other words, in microservice architectures, the bounded context is also a physical context. But that also means that this service implementation isn’t coupled to any other team’s implementation, clearing the path for independent evolution. I recently published some writing about the recent realization that architecture is abstract until operationalized. In other words, until you have deployed an architecture and upgraded parts of it, you don’t fully understand it.
The shape of software architecture
Five things we learned from the O’Reilly Software Architecture Conference 2015.
Last week, I had the opportunity to see the first Software Architecture Conference spring to life after a winter of preparation. Software architects, with or without the official title, swarmed the halls learning from speakers and attendees alike. I count myself among the people who were learning. Many notions about this profession and skill set have become clearer to me and I’m already planning to keep the content coming. I’m also in the early stages of developing out the next Software Architecture Conference (spring 2016).
Within this piece you’ll find my takeaways and lessons learned from the event. I expect these initial impressions to both shape our upcoming exploration of software architecture and be shaped by continued shifts within software architecture.
Read more…
How the DevOps revolution informs software architecture
The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.
In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.
Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:
“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”