Earlier this year, Andrzej Frydryszak, .NET Developer at ITMAGINATION attended a few conferences on software development. The list we compiled is a list of the most significant points the attendees of the conferences have heard from some of the top engineering leaders in the US & Europe. Here goes:
1. Observability [Tracing, Monitoring & Logging] is crucial!
You are working on your software, and you are ready to deploy it. All tests pass, and test coverage is on a decent level. Knowing this, we may deploy our code, and continue to work on it in peace. As much as this is not the optimal scenario (and as rare as it is) our code may still fail. Yes! Therefore developers need to always observe their code, and have it report metrics all the time. In case anything fails, you need to have your systems ready to deliver your logs to you. As Andrzej writes:
Observability is crucial. Without it, developers are blind. It gives us an opportunity to react to every problem occurring in the system at any time.
2. It’s a good practice to use both the “serverless” & “serverful” approaches. In that case, we benefit from both approaches to software development.
Serverless is a way of running apps (seemingly) without any servers involved. Of course, it is a major simplification – there are always servers involved; only in this case you do not do anything with them, and they come preconfigured. It’s touted as the new black, except… It’s not a perfect remedy to all ailments. For starters, you cannot configure the underlying server, as we mentioned before. You don’t really know what’s under the hood, either. The main drawback is the approach’s major benefit at the same time. You don’t have to configure anything, so instead of deploy ⇾ worry, it’s more of a deployment ⇾ forget.
There are benefits of either serverless or serverful solutions. In the modern systems, it is common to join two approaches to gain most of the solution.
3. Containerize everything! Kubernetes is a hot technology!
Not all software development trends are good ideas. Do you remember CoffeeScript or Ruby? Sadly, we do. Luckily, Kubernetes (K8S) don’t seem as if it’s are going to join the two in the valley of sorrow. K8S are making DevOps specialists lives’ much, much, easier.
Here are the benefits you can expect by introducing containerization and container orchestration as a core tenant of your technology strategy:
- You will be able to easily optimize your IT infrastructure costs
- Your users can expect higher availability and better SLAs due to seamless scalability
- Using Kubernetes enables your team to use multi-cloud solutions more easily
- Since containers and container orchestration tools are technology-agnostic, you can build using any technology that you want with a leaner team
- You no longer run into the age-old “it works on my machine” issue by containerizing
Beyond the obvious benefits, we’ll leave you with some case studies that we hope will inspire you and help you decide if using Kubernetes is right for you, as well as show more in-depth benefits:
- Northwestern Mutual Case Study | Kubernetes: after acquiring a fintech startup, Northwestern Mutual had to consolidate workflows between cloud-native and on-prem processes, deploy more often, and unify their team’s operations to ensure their customers kept getting the same seamless experience they had been used to.
Using Kubernetes helped them increase their deployment velocity by over 25 times from 24 in a year to over 500 in 10 months, planned outages are a thing of the past, and infrastructure costs decreased significantly thanks to their API management being part of their overall stack that’s deployed on Kubernetes.
You can read more about these points, the transition to AWS, using Microservices, renewed developer autonomy, and keeping their 4.5 million customers happy with the quality and speed of their services in the case study.
- Capital One Case Study | Kubernetes: in Capital One’s case, bottom-line is a big topic. Their estimates show that without using K8s’ ability to scale up and down automatically and easily, their AWS infrastructure costs would easily triple or even quadruple.
Other benefits they’ve seen by using Kubernetes is time-to-market for new products, which now takes as little as 2 weeks, whereas it could have taken 3 or more months before.
The main reason for starting to look at Kubernetes for their development? Capital One’s team wanted to increase the speed at which they’re able to process streaming data for key decisions in the areas of fraud detection and credit decisioning, as well as for other big data and machine learning applications that are critical to the day-to-day operation of the bank.
You can read more about these points, the deployment speed increases, how K8s helped unify Capital One's development environment, and more in the case study.
Other intesresting case studies worth checking out:
- Pearson Case Study | Kubernetes: reducing time-to-market for new features, increasing provisioning speeds from months to minutes, and ensuring high SLAs for an education company serving 75 million users.
- Prowise Case Study | Kubernetes: zero downtime between application versions, hours to seconds for new deployments, and new releases sped up by 3x in a complex development environment that includes many products.
- Zalando Case Study | Kubernetes: the European fashion e-commerce leader used K8s for scalability, enabling multiple business use cases like same-day-delivery, multi-tenancy, increasing their offering and geographical reach, and enabled them to re-write and create all the SaaS products they had been using as custom software.
- adidas Case Study | Kubernetes: e-commerce site load times were cut in half, releases were done multiple times a day instead of once a month, and developers have much more autonomy thanks to adidas’ move to being cloud native.
- Booking.com Case Study | Kubernetes: after using OpenShift and learning the ropes of how to use Kubernetes, Booking.com’s team shifted to their own vanilla version of K8s to enable their developers to be more autonomous, independent, and not have DevOps be their perceived bottleneck.
Have any questions about how to optimize your K8s deployments or whether it’s the right choice for you at your current scale? Make sure to reach out to us to talk to Maciej Gos, our DevOps competency leader.
4. When it comes to software architecture, we should divide & conquer
Monoliths of large sizes are somewhat of a yesterday’s tale. They haunted developers for long, though not anymore. Splitting huge unitary codebases into smaller scale apps is the new way of doing things. It fireproofs your applications, reducing the frequency of errors, and making apps safer in case something wrong happens. The downside is, apps become harder to test, and it takes more resources to do so. For teams of a smaller size, it still makes more sense to maintain a monolith.
Divide a monolithic application into independent microservices.
5. Open-Source & Free Software are the ways of the future.
React, Angular, and Zuul, from Meta (which used to be Facebook), Google, and Netflix, respectively, are tools countless developers use in their jobs every day. Without the tools these organizations released at no cost to all those willing to use them, everybody’s job would have been much more difficult. Countless services would not have seen the light of day, as it would have been too hard or too time-consuming to write these apps. All because, before writing them, one would have to figure out how to e.g., write front-ends for scale, on their own, without sharing the lessons learned would be extremely inefficient.
This is why we have to praise open-source & free software maintainers, creators, and all others contributing to the creation and maintenance of such software.
Creation of a tool/technology and making it open-source (or making it free) gives the organization eternal glory.
6. Use Architectural patterns.
There is a common rule in software development – don’t reinvent the wheel. Knowing that we likely have faced the same problem as somebody else before, the rule becomes all the more valuable. This is why engineers and developers from around the world use Architectural Patterns to structure their projects – not to waste time on thinking about how to figure out solutions others already came up with.
Much of modern pieces of software use patterns like CQRS and Event Sourcing. Don’t reinvent the wheel, use the patterns.
7. Programming languages are evolving.
The fact that we have newer and newer programming languages isn’t a surprise. They all come and go, and leave to be replaced by others. Nobody codes in Algol or Pascal anymore. One old-timer, C, is still around, however, though that’s a topic worth exploring on its own.
One noteworthy aspect is the way in which they all evolved during the years. At first, imperative languages were the only ones around. Then the boom for Object-Oriented languages came, and now, some might argue, that they are being pushed out by languages such that are much more flexible, mixing some imperative, functional, and object-oriented features.
The way languages evolve is getting more and more independent of the systems we work on, and with. Modern languages are cross-platform. Thanks to the growth of DevOps, the language selection becomes less and less important.
8. Thanks to the modern infrastructure, complexity is moving from the application to the external platforms.
The classic infrastructure on a physical server in the basement is displaced by cloud providers and related technologies. We have VMs as a service, data bases as a service and many other infra elements as a service. Major of planning in a software solution has moved to the high level design of an infrastructure since much can be automated based on it. Additionally, we have containers and container orchestration. It takes over the complexity, since we can divide the system into smaller and simpler parts.
Application code gets more independent of the platform. The complexity, however, lies in the infrastructure and operations. Application developers focus increasingly on business logic. DevOps engineers handle the rest.
9. SCRUM != AGILE
Adopting specific processes usually leads to learned behaviors, which ultimately lead to habits. At least, that’s the theory of it.
In some cases however, processes stay processes that people trudge through just to go through the motions, but the behaviors never develop. Think of it this way, how many development teams have you seen go through all the Scrum rituals but not actually working in an agile way? Too many? We agree.
So what can you do? First of all, team buy-in, this is always the first step that needs to be established. If your team does not see the value in working using this methodology, then all the processes and rituals will not move the needle much in the long term.
The second step is to make sure you have a great scrum master and project manager to ensure good practices are being passed onward and that any objections are being
The third step is to realize: forcing Agile values & the Scrum framework down people’s throats when it doesn’t hold any merit will get you nowhere, fast. We’ve covered this point and many more in detail in our post titled ”Scrum isn’t the answer for every IT project (itmagination.com)”.
SCRUM can be agile, but it does not guarantee agility. Agility comes from behaviors, not only processes.
10. Continuous Security
As we wrote many times before, security cannot be an afterthought. We cannot simply “leave it for later.” Checking apps for security issues has to be integrated into the DevOps process, and into the development process itself from day one. Luckily, there are few tools we may use to make the process frictionless. One of them is Snyk. It’s a comprehensive tool to “[f]ind and automatically fix vulnerabilities in your code, open-source dependencies, containers, and infrastructure as code[…].”
We must apply security checking procedures in the development cycle. Security is a base of trust – the currency of the future.
11. Audit the prices of cloud provider’s services
As the three main cloud providers enjoy virtually no competition, and differences in services they provide are (more or less) arbitrary. The only difference that we may see, realistically, is the difference in the price of services. This is why, being biased about this one particular provider is not necessarily bad. There really is, mostly, little to no difference.
Choose whichever provider you are comfortable with, and already know. Assess as you go, and don’t be afraid of change.
Cloud providers have no virtual competition and no cost arbitrage. Cloud infrastructure costs are very dependent on inflation and recession.
12. Everything can be done “as a Service”.
Platform as a Service, Infrastructure as a Service, Database as a Service, Software as a Service, Backend as a Service… We spared you more examples, and you should get our point across. Everything you can think of can be done by a third-party and sold to you.
Using these services is a trade-off. You give up some control to become leaner, and to be able to iterate faster, as well as to save some money upfront.
Due to the growth of the importance of cloud providers and serverless approach, every piece of software can be done as a Service.
13. Everybody uses Visual Studio Code.
Visual Studio Code took the world by storm. The combination of having the backing of Microsoft, having an Open-Source license, being written in TypeScript, and allowing for an easy extension of functionality were great decisions. The text editor is, by far, the most popular choice among modern programmers. Other choices, such as Intellij-based Integrated Development Editors (IDEs) or Vim, are in Code’s shadow, though JetBrains’ Fleets might change that.
Thanks to the multiple extensions and customization tools, VS Code becomes the most popular IDE among developers.
14. TensorFlow is widely used these days.
Thanks to TensorFlow we can implement AI solutions in web applications. The models for training are provided by the library. Developers should focus on training them.
15. A great long-term hiring strategy is to hire juniors and train them.
Hiring juniors is a good long-term strategy. While there is no “best strategy” that’s a fit for all companies, hiring juniors and training them is definitely one of the best ways to grow and retain in-house talent.
Hiring juniors is a great way to scale up your team slowly over time, and building an internal culture that is easier to mould when compared to hiring people who are possibly set in their ways. Juniors also give a fresh perspective and are more in touch with current trends.
There are a few cases where this isn’t ideal, for example when you your company needs to scale and develop new features very quickly. It’s also not the best if you have a small in-house team who are always trying to catch up with their backlog due to unrealistic development expectations. In that case, hiring an external technology partner to help with development while scaling up the in-house team in tandem could be a great middle-ground solution.
Hiring juniors to train them as a strategy doesn’t come without pitfalls. Juniors who are on your team are not vetted by previous companies, they don’t have a work history, and it may very well be a hit or a miss. The unfortunate reality is that while this strategy can be great with appropriate compensation packages, junior employees may find themselves in positions where they can double, triple, or even quadruple their salary by simply moving companies, rather than waiting or pushing for a promotion or raise.
This is why it’s so important to have transparent salaries and pay scales to show people where and how they can advance in their career path. This is why it’s also very important to have great onboarding programs to make sure that the time spent on training the juniors is well-spent and benefits both the mentors and mentees.
According to numerous studies, a great long-term hiring practice for software developers is to hire non-experienced engineers and train them into the ways of the organization.
That's it. Fifteen of the most impactful trends in 2023. Which one is the most impactful in your regard? Did wemiss any? Let us know!