Twitter

Category: Thoughts

Getting started on a microservice adoption isn’t trivial given the challenge of migrating existing data, merging with other data sets, keeping yourself in a ‘known good state’, and the new requirement of honoring contracts long after you’ve moved onto a new way of doing something. At least it’s just a technical problem that can easily be changed and monitored over the course of it’s implementation. I covered some options to start that half of the work in my prior microservice article and isn’t a goal here.

The real challenge comes in the other half of the work to lay the foundation for the microservices effort – the path to a DevOps supporting culture – which is our goal for this sub-section of the “working towards microservices” series. It’s the hardest half of the two parts given that it’s a business problem that can’t be easily changed or monitored – it requires changing the organization’s culture. Unlike computers which change their logic processing with a deployment, humans are pretty stubborn when confronted with new information, or conflicting ideas and thoughts.

You can’t directly change the culture just like you can’t directly change a person’s personality. You can change the culture indirectly by modifying behavior through the implementation of an intrinsic motivation and reward system, or working towards the implementation of a social-norm culture.Continue reading

In the work that I’ve done recently for evangelizing the principles behind our DevOps movement, it was interesting to hear the question of how microservices has anything to do with DevOps at all. It seems my blogging and marketing within the company is working as neither concept was widely known at the time I had started there and now people are getting to get the concepts well enough to know the difference.

They are very much correct in stating that microservices is an architectural concern and not something that DevOps dictates or even talks about. Even today, I am still marketing both DevOps and microservices in almost the same breath in most conversations. I have changed my messaging a to remove the confusion and put more emphasis on what each aims to resolve.Continue reading

I want to start off by saying that having a monolithic application isn’t always a bad thing, and this article may not necessarily be for you. Yet. It just comes down to the correct timing of using microservices when it make sense and then diving into that work at the moment it’s needed, and not a moment later. Utilizing a microservices architecture too soon will hold you back and slow the development process back, whereas waiting too long to perform the migration makes the refactoring effort very painful.

If you have a single product that was designed well, is easily maintainable, and carries minimal technical debt, you may not have a lot of reasons to invest into a microservices architecture. Or certain areas are becoming areas of concern for performance and scalability, then you may slowly split those areas out.

If you’re like the rest of us dealing with multiple products through acquisitions, mergers, or reorganizations that were originally built in a time long ago before best practices existed for online services, there is little hope that it is maintainable or carrying minimal technical debt.

A lot of people have asked me over the past year or so why I left Seattle. Well, here are over 445 accolades (nine years worth) the Raleigh area was awarded that partially helped weigh the decision to move here over any other city in the United States. The reasons you would want to move here won’t necessarily match ours, so I didn’t filter them.

To be completely transparent with you, I am not currently (or have ever been) employed by any company on this list, and have no financial incentives as a result of posting this. I just live here.

I covered this in my lasttwo posts, but the Spek language that I’ve been slowly working on over the past few months is based on the Axum programming language originally developed by Microsoft about five years ago. I’ve been making changes to the Axum language’s grammar after spending a couple of weeks painstakingly trying to recreate it. The area I’m working to change at the moment are channels and ports.

To recap where we are: channel patterns are entirely out, channel ports have been updated, channel functions just came back from vacation, and a couple of feature ideas for channels in the future to share.Continue reading

I covered this a bit in my last post, but the Spek language that I’ve been slowly working on over the past few months is based on the Axum programming language originally developed by Microsoft about five years ago. I’ve been making changes to the Axum language’s grammar after spending a couple of weeks painstakingly trying to recreate it. The area I’m working to change at the moment are channels and ports.

To recap where we are: channel patterns are entirely out and channel functions are on holiday until further notice.Continue reading

I’m having a hard time trying to understand how Microsoft open sourcing .NET is going to help them, at least financially. I get that developers want to have the option of running on Linux, and that by doing this, they win the development community. Microsoft has a horrible history of not always choosing right over profitable.

With the status quo prior to this last week, the use of .NET on non-Windows machines meant you were a year or so behind the curve by using Mono. At least depending on what you wanted to implement – some of the asynchronous parts of the MVC framework is still out of reach, and both WPF and WCF were left entirely unimplemented.Continue reading

Share

I haven’t touched the Spek project in a few weeks and decided to give it some attention tonight. In playing with Java, Ruby, Python, and Node.js over the past couple of months, I’ve wondered what sort of additional syntax or overall languages changes I should consider before finishing the grammar.

The Spek language is pretty much a duplicate of the Axum language developed by Microsoft back in 2009. I’ve only made a really small change to the syntax for how a developer would interact with a channel and possible network operators, but the rest of the language is exactly the same so far.Continue reading

Unless you have some really great connections, every type of debt I have ever had the displeasure of dealing with has come with some sort of interest payment. If your company has adopted Agile software development methodologies (Scrum, Kanban, XP, etc), but is only delivering software on a quarterly basis (or less often), chances are that you are paying a ‘release debt’ with interest.

If the concept of ‘technical debt’ could be overly simplified as ‘stuff that you’ve been meaning to fix‘, then you could easily view release debt as ‘stuff that you’ve been meaning to deploy‘.Continue reading

Share

For someone who can barely keep his blog up to date, I would still love to write a book one day. I’ve been told I have a great amount of technical talent multiple times, can sometimes firehose people asking for an intro to a topic, or get a bit detailed. So I’ve got plenty in my head to share, I’m just not sure on how to distill the knowledge I have and what topics people would be genuinely interested in reading. My frontrunners for the topics I’d love to write about are:Continue reading