CodeIsGo.com

This post will reveal author’s experience of working in multiple startups. The views are completely driven based upon his personal experience and can be found biased. By Navneet Maheshwari.

Author realizes in recent times and strongly believe that the startups for whom tech is not the primary product should not get into building platforms from scratch at an early stage of their journey. There are multiple reasons for this including volatile business model which keeps on reiterating and evolving, the talent acquisition cost for the tech team that is very high, there will be a very high business learning quotient for developers, leading to a lot of communication, it takes a lot of time to build stable tech etc.

With the recent development in the Low code space, I feel startups should focus on building tech with these platforms before jumping on building a complete in-house stack. With the recent development in the Low code space, author feels startups should focus on building tech with these platforms before jumping on building a complete in-house stack.

There arises a plethora of platforms that can help you build any software without much need for engineering bandwidth. The Low-code/ No-code platform can be classified into the following segments:

• Frontend: (Website Builder, E-comm, Landing Page builder, etc). Some of them are Shopify, Webflow, WordPress, Wix, etc.
• Mobile App: (App Builder). Appsheet, Glide, Shopney, etc.
• Backend: Builder.io, Bubble, ERPNext

Author worked in 3 startups so far and there are is one thing that is common; Building Tech products is difficult: It’s not just simply coding and delivering a project. It’s a continuous reiterative process. Good read!

At Replay, we’re building a true time-travel debugger for JavaScript. Our technology records everything that happens in a browser, so you can use it to debug any page regardless of what frameworks or libraries were used to build it. That said, framework-specific devtools are a valuable part of the debugging experience. By Mark Erikson.

Replay’s recording capability is built into our custom forks of the Firefox and Chrome browsers and Node runtime. Firefox has been our primary recording browser thus far, but in Q4 2022 we started improving the Chrome fork to reach feature parity with Firefox. One of the missing features in Chrome was React DevTools support.

The article then describes in depth:

• Background
• How do the React DevTools work?
• Replay’s React DevTools support in Firefox
• Replay’s recording analysis APIs
• Using “Routines” for recording analysis
• Browser integration, stubs, and annotation timestamps
• Writing annotations for processing recordings
• Evaluating code in recording pauses
• React DevTools routine implementation
• React DevTools client-side implementation
• Deployment

… and more. The React DevTools backend was only designed to run in a real browser, and author pretty sure our protocol API wasn’t designed with “evaluate entire JS bundles” in mind. Happily, both were designed well enough that something like this was possible. Along the way, author learned a lot about our backend protocol API, how pauses work, evaluating JS as strings, and doing development + deployment on our backend repo. Godo read!

The NIST Cybersecurity Framework (NIST CSF) is a voluntary framework developed by the National Institute of Standards and Technology (NIST) to help organizations manage cybersecurity risk. It was created via an executive order from President Obama in 2013 to improve cybersecurity within critical infrastructure. By Julien Katzenmaier.

It provides a risk-based approach to identify, assess, and prioritize risk, and to develop and implement a comprehensive strategy to reduce it. It is composed of five core functions—Identify, Protect, Detect, Respond, and Recover—and ties into other NIST standards, guidelines, and best practices. The framework provides organizations with a flexible, repeatable, and cost-effective approach to managing their cybersecurity risks.

However, for organizations to meet NIST cybersecurity framework compliance, they must adopt a holistic approach toward cybersecurity, ranging from various practices, policies, and tools. Consult the article for table which shows how Sepio’s Asset Risk Management solution can help your organization align with NIST cybersecurity framework compliance so that you can manage risk properly and effortlessly. Good read!

How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think. By Natalie Somersall.

The cost of hardware is one of the most common objections to providing more powerful computing resources to development teams—and that’s regardless of whether you’re talking about physical hardware in racks, managed cloud providers, or a software-as-a-service based (SaaS) compute resource. Paying for compute resources is an easy cost to “feel” as a business, especially if it’s a recurring operating expense for a managed cloud provider or SaaS solution.

The article details:

• Testing build times vs. cost by core size on compute resources
• How much slow build times cost companies
• How much context switching costs companies

When you ask a developer whether they’d prefer more or less powerful hardware, the answer is almost always the same: they want more powerful hardware. It’s cheaper—and less frustrating for your developers—to pay more for better hardware to keep your team on track.

In this case, spending an extra $4-5 on build compute saves about $40 per build for an individual developer, or a little over $200 per build for a team of five, and the frustration of switching tasks with a productivity cost of about an hour. That’s not nothing. Of course, spending that extra $4-5 at scale can quickly compound—but so can the cost of sunk productivity. Interesting read!

In the new project, there is no logging system at all, and since we all love the Grafana stack, we also decided to use Loki for logging. Loki is built on a microservices architecture, with all microservices assembled into a single binary. By Arseny Zinchenko.

The article then makes a good job explaining:

• Grafana Loki architecture
• Loki components
• Data flow
• Read Path
• Write Path
• Simple scalable deployment mode
• Microservices mode
• Grafana Loki Storage
• Loki Helm charts
• Helm chart, and Deployment Mode

… and more. All commands and configuration included. Loki receives data from multiple streams, where each stream is a tenant_id and a set of tags. When receiving new records from the stream, they are packed into chunks and sent to long-term storage, which can be AWS S3, a local file system, or databases such as AWS DynamoDB or Apache Cassandra. Interesting read!

Building service is easy. Isolating that service, it’s easier said than done. Anyone can build any service with any technology or stack. However, would this service last, or will it become technical debt? Many organizations trying to go all in with microservices end up with distributed monoliths instead of isolated services. By Diego Pacheco.

Because code isolation is not enough. We need to isolate the 3 frontiers being:

• Contracts
• Databases
• Internal shared libraries

Shared database is the most common mistake companies make. They create new services, but all share the same databases. Fixing this problem is hard. But possibly, there are patterns and approaches we do to fix database sharing. Like the Strangler Fig Pattern and many data migrations patterns.

Contracts matter more than implementation. Services are composed of 2 elements. The service contract and the service implementation. Contracts are the most important piece. Period.

Isolating internal shared libraries. This is the most controversial yet big problem all companies face, but only some realize how bad it is. Internal common shared libraries, most of the time, are evil and bring more problems them solutions. Authort lost count of how many companies, products, and projects he worked on that had bad libraries. They are everywhere in the industry. Interesting read!

How do you prevent the most common merge conflicts when your team is working on a Serverless application? How do you make sure that your team stays productive and avoids large merge issues while trying to update the same crucial files simultaneously? By Mark Curtis, Juan Peredo, and Tom Romano.

When multiple developers collaborate on a serverless architecture built with AWS CloudFormation, and its extensions such as the AWS Serverless Application Model (SAM), the nature of specifying resources in both the template.yaml and the optional OpenAPI.yaml specification for Amazon API Gateway leads to merge conflicts. These conflicts detract from the developer’s time and agility. Furthermore, navigating and maintaining the long template files required for a larger serverless architecture slows development as the developer scans large files to find a particular resource definition.

The article then describes solution to this problem:

• Rapid development
• Sample project
• OpenAPI and AWS service integration
• cfn-include and nested stacks

Following techniques mentioned here, you should be able to:

• Improve developer efficiency by decomposing large, hard-to-manage files into a series of well-organized and single purpose files
• Enhance developer productivity by allowing each developer to have ownership of their own piece of the code without having to coordinate with teammates
• Eliminate potential merge issues on the files that typically generate the most conflicts during the development of a typical Serverless API application

This post demonstrates techniques used by WRAP and AWS to rapidly develop and maintain key files in an Serverless architecture. Nice one!

As per the latest forecast by Gartner, worldwide IT spending is projected to amount to $4.6 trillion in 2023, up by 5.1% from 2022. The demand for IT will be strong in 2023 as enterprises launch digital business initiatives to respond to global economic challenges. By Srinivas Miriyala.

You will find information on following topics in this article:

• Why IT operations might cost more in 2023
• Gartner’s decision framework for cost optimization
• 7 strategies to optimize IT costs in 2023
  • Align automation approach with use cases to minimize technical debt
  • From infrastructure-centric to customer-centric operations (observability)
  • Capture immediate value from AIOps
  • Enhance self-service, autonomy and decentralization with governance and ITSM
  • Automate incident management
  • Balance speed of innovation with IT risk management
  • Judiciously use IT Ops teams

In order to optimize IT costs going into 2023, it’s critical to take note of where your IT employees stand on wellness and productivity and to take necessary steps to address concerns, if any. Good read!

During AnsibleFest 2022, we announced the launch of Ansible validated content. This new initiative is focused on delivering an expert-led approach for automating your platform portfolio across infrastructure, networking, cloud, security and edge use cases. By Massimo Ferrari.

The blog post then explains:

• Why should I care about Ansible validated content?
• What does “validated” mean?
• What is Ansible validated content for?
• What does Ansible validated content look like?
• Where can I find Ansible validated content?

Validated content stems from and complements Red Hat’s Validated Patterns initiative. A selection of Ansible content is curated by experts like the Red Hat Automation Community of Practice. Good read!

Tests are vital parts of our systems. Easy to understand and modify tests will help us in keeping the project in good shape for long period of time. First we may start with synchronous code, however sooner or later we will need to start processing part of our flows asynchronously, and this is when Message Driven Architecture becomes handy. By Dariusz Gafka.

Further in the article:

• Asynchronous execution
• Running Publisher and Consumer in separate processes
• Running asynchronous code as synchronous
• Running Consumer with in memory channel
• Switch from Polling to Event-Driven
• Limit scope of your tests

Testing message driven architecture may be challenging, due to decoupled nature and asynchronicity. However it comes with so many pros, especially when the system grows, that is becomes a need at some point of time. Good read!