"microservices" entries

Four short links: 25 August 2015

Four short links: 25 August 2015

Microservices Anti-Patterns, Reverse Engineering Course, Graph Language, and Automation Research

  1. Seven Microservices Anti-PatternsOne 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.
  2. CSCI 4974 / 6974 Hardware Reverse Engineering — RPI CS course in reverse engineering.
  3. 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.
  4. 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.
Comment

The cloud-native future

Moving beyond ad-hoc automation to take advantage of patterns that deliver predictable capabilities.

window_panes

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.

Read more…

Comment
Four short links: 9 April 2015

Four short links: 9 April 2015

Robot Personalities, Programmer Competency, Docker Dependencies, and Large Files in Git

  1. 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.
  2. Programmer Competency Matrix — a rubric for developer development.
  3. Aviator — Clever’s open source service dependency management tool, described here.
  4. Announcing Git’s Large File Storagean improved way to integrate large binary files such as audio samples, data sets, graphics, and videos into your Git workflow..
Comment

4 reasons why microservices resonate

Microservices optimize evolutionary change at a granular level.

hive

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.

Read more…

Comment

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…

Comments: 5

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.

hans_christian_hansen,_architect_seier+seier_Flickr

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.”

Read more…

Comment: 1

Signals from the O’Reilly Software Architecture Conference 2015

From careers to culture to code, here are key insights from the O'Reilly Software Architecture Conference 2015.

Experts from across the software architecture world came together in Boston for the O’Reilly Software Architecture Conference 2015. Below we’ve assembled notable keynotes, interviews, and insights from the event.

Software architects: post-“post-useful”

The old notion of a software architect being a non-coding, post-useful deep thinker is giving way to something far more interesting, says Neal Ford, software architect and meme wrangler at ThoughtWorks. “Architecture has become much more interesting now because it’s become more encompassing … it’s trying to solve real problems rather than play with abstractions.”

Read more…

Comments: 2
Four short links: 26 February 2015

Four short links: 26 February 2015

Autocompletion, Colliding Trends, Microservices, and Writing Useful Code

  1. awesomplete — MIT-licensed ultra lightweight, usable, beautiful autocomplete with zero dependencies in Javascript.
  2. How to Seize the Opportunities when Megatrends Collide — excuse the cheesy title, the chart from PwC showing pairwise combination of trends, is interesting.
  3. Adopting Microservices at Netflix: Lessons for Architectural Designyou want to think of servers like cattle, not pets. If you have a machine in production that performs a specialized function, and you know it by name, and everyone gets sad when it goes down, it’s a pet. Instead you should think of your servers like a herd of cows. What you care about is how many gallons of milk you get. If one day you notice you’re getting less milk than usual, you find out which cows aren’t producing well and replace them. People for Ethical Treatment of Iron, your time has come!
  4. Your Job is Not to Write Code (Laura Klein) — I know what you’re thinking. This will all take so long! I’ll be so much less effective! This isn’t true. You’ll be far more effective because you will actually be doing your job. Amen to it all.
Comment
Four short links: 22 January 2015

Four short links: 22 January 2015

MSVR, The Facebook, Social Robots, and Testing Microservices

  1. Microsoft HoloLens Goggles (Wired) — a media release about the next thing from the person behind Kinect. I’m still trying to figure out (as are investors, I’m sure) where in the hype curve this Googles/AR/etc. amalgam lives. Is it only a tech proof-of-concept? Is it a games device like Kinect? Is it good and cheap enough for industrial apps? Or is this the long-awaited climb out of irrelevance for Virtual Reality?
  2. The Facebook (YouTube) — brilliant fake 1995 ad for The Facebook. Excuse me, I’m off to cleanse.
  3. Natural Language in Social Robotics (Robohub) — Natural language interfaces are turning into a de-facto interface convention. Just like the GUI overlapped and largely replaced the command line, NLP is now being used by robots, the Internet of things, wearables, and especially conversational systems like Apple’s Siri, Google’s Now, Microsoft’s Cortana, Nuance’s Nina, Amazon’s Echo and others. These interfaces are designed to simplify, speed up, and improve task completion. Natural language interaction with robots, if anything, is an interface. It’s a form of UX that requires design.
  4. Microservices and Testing (Martin Fowler) — testing across component boundaries, in the face of failing data stores and HTTP timeouts. The first discussion of testing in a web-scale world that I’ve seen from The Mainstream.
Comment
Four short links: 22 September 2014

Four short links: 22 September 2014

OS X Javascript, Social Key Party, E-Fail, and Microservices Testing

  1. Significance of Javascript For OS X Scripting — not just for shell scripting-type automation, now you can build Cocoa applications with Javascript. This is huge.
  2. keybase.io — social media as trust vector.
  3. I Banned E-Mail At My CompanyEmail should not be used to share information. Especially if that information is a resource that might be useful again in the future.
  4. Building Microservices at KarmaThe biggest challenge with microservices is testing. With a regular web application, an end-to-end test is easy: just click somewhere on the website, and see what changes in the database. But in our case, actions and eventual results are so far from another that it’s difficult to see exact cause and effect. A problem might bubble up from a chain, but where in the chain did it go wrong? It’s something we still haven’t solved.
Comment