Simply moving your application to a microservice-based architecture is not sufficient. It is still possible to have a microservice-based architecture, but have your development teams work on projects that span services and create complex interactions between your teams. Bottom line: You can still be in the development muck, even if you move to a microservice-based architecture. To avoid these problems, you must have a clean service ownership and responsibility model. Each and every service needs a single, clear, well-defined owner who is wholly responsible for the service, and work needs to be managed and delegated at a service level. I suggest a model such as the Single Team Oriented Service Architecture (STOSA). This model, which I talk about in my book Architecting for Scale, provides the clarity that allows your application—and your development teams—to scale to match your business needs. Microservice architectures do come at a cost. While individual services are easier to understand and manage, a microservices application as a whole has significantly more moving parts and becomes a more complex beast of its own.
One of the most opinionated feature of Routine is the dashboard. Whatever you’re doing on your computer, you can pull up the Routine dashboard with a simple keyboard shortcut. By default, that shortcut is Ctrl-Space. The Routine app adds an overlay on top of your screen with a few widgets. It looks a bit like the now-defunct Dashboard on macOS. On that dashboard, you’ll find a handful of things. On the left, you can see the tasks you have to complete today. On the right, you can see how much time you have left before your next meeting and some information about that event. The date is pulled directly from your Google Calendar account. In the center of the screen, Routine displays a big input field called the Console. You can type text and then press enter to create a new task from there. It works a bit like the ‘Quick Add’ feature in Todoist. The idea is that you can add a task without wasting time opening your to-do app, moving to the right project, clicking the add task button and entering text into several fields. With Routine, you can press Ctrl-Space, type some text, press enter and you’re done.
Whatever algorithm you implement or analysis you make, the results are used in the continuing processes or production. Thus, it is of vital importance to make sure the results are correct. By results being correct, I do not mean not having any errors on your predictions or hitting 100% accuracy which is not reasonable or legitimate. In fact, you should be really suspicious of results which are too good to be true. The mistakes I mention are usually data related issues. For instance, you might be making a mistake while joining stock information of products from an SQL table to your main table. It results in serious problems if your solution is based on product stocks. There are almost always controls in your code that prevent making mistakes. However, it is not possible for us to think of each and every possible mistake. Thus, taking a second look is always beneficial. ... The glorious world of machine learning algorithms is very attractive. The urge for using a fancy algorithm and building a model to perform some predictions might cause you to skip digging into the data.
"Remote workers need to be aware that IoT devices could be compromised and used to move laterally to access their work devices if they're both using the same home router, which in turn could allow attackers to move onto corporate systems," said Palo Alto. Poor IoT device security stems mainly from manufacturers' desire to keep price points low, cutting security out as an unnecessary overhead. This approach inadvertently exposed large numbers of easily pwned devices to the wider internet – causing such a headache that governments around the world are now preparing to mandate better IoT security standards. Even IoT trade groups have woken up to the threat, albeit perhaps the threat of regulation rather than the security threat, but if that's what it takes, the outcome is no bad thing. ... Half of respondents said they worried about attacks against their industrial IoT devices, with 46 per cent being similarly worried about connected cameras being compromised. Smart cameras are a tried-and-trusted compromise method for miscreants
There are many reasons behind the rise of no-code and low-code tools, but the key one is a large imbalance between the ever-growing demand for software development services and the shortage of skilled developers in the market. For decades, there's been movement toward a withdrawal from complicated coding in favor of easy-to-use visual tools. However, over time, no-code and low-code platforms have become more sophisticated, allowing non-developers to build more powerful websites and applications without hiring software specialists. That has even evoked some neo-Luddite concerns and discussions about the potential of such platforms to make good old software developers obsolete. But what’s behind it? Both no-code and low-code approaches hide the complexities of software programming under the mask of high-level abstractions. Low-coding reduces programming efforts down to minimum levels, and no-coding empowers anyone to create apps without any knowledge in programming.
There is one aspect to this that I think is worth talking about, and that is that we actually already have an organization of people. We work in organizations that are, in general, organized into teams. You see a theoretical org chart here on the left. This might look like something that you might see in your own companies. We have these org charts, and these organizations of teams. Then that org chart doesn't map very neatly onto the microservices architecture necessarily, and maybe it shouldn't. The interrelationships between these teams are actually more subtle and often more complicated than what you see in the org chart. That is because if you have microservices, and you have dependencies between these microservices and interactions between them, then the teams owning them, by necessity, sometimes need to interact with each other. Microservices are constructed in a way that gives as much independence as possible and as much autonomy as possible to the individual teams.
Companies’ public commitments to ambitious—and sometimes expansive—goals tend to have multiyear timelines, while agile teams are trained to focus on the next three to six months. In organizations with siloed processes, product owners often feel that they don’t have enough visibility into their organizations’ processes to forecast the timeline for their initiatives, let alone to predict the long-term impact of their work. To balance the demands of the near future with longer-term goals, the companies that meet their transformation goals support agile teams with information and expertise. Successful companies provide product owners with relevant financial and operational data for the company, benchmarked to best-in-class organizations, to help them assess the potential value of their work for the next 18–24 months. They also assign initiative owners and relevant subject-matter experts from business functions early in the research and discovery process to help quantify possible improvements to the existing journey.
Even with smaller satellites, building a profitable wireless network is hard. On one side, there’s a capital-intensive phase that requires establishing connectivity (in this case, by building and launching satellites) and on the other, these companies must establish a market for the connectivity. But while the economics of building and launching satellites have changed dramatically, the demand for devices that rely on satellite networks hasn’t kept up. The biggest growth has come from people-tracking products, such as the Garmin inReach walkie-talkies, which people can wear into the wilderness and use to get help if needed. There are also rumors that Apple may include some form of satellite service in an upcoming iPhone. While this is a real and growing market, however, it isn’t enough to justify the launch of constellations by almost a dozen companies whose goal is to be IoT connectivity providers. So former connectivity players eschew bandwidth and turn to full solutions in order to provide a service that isn’t a commodity and eke out more revenue per customer.
When an application is caching many objects in memory, ‘GC’ events wouldn’t be able to drop the heap usage all the way to the bottom of the graph (like you saw in the earlier ‘Healthy saw-tooth pattern). ... you can notice that heap usage keeps growing. When it reaches around ~60GB, the GC event (depicted as a small green square in the graph) gets triggered. However, these GC events aren’t able to drop the heap usage below ~38GB. Please refer to the dotted black arrow line in the graph. In contrast, in the earlier ‘Healthy saw-tooth pattern’, you can see that heap usage dropping all the way to the bottom ~200MB. When you see this sort of pattern (i.e., heap usage not dropping till all the way to the bottom), it indicates that the application is caching a lot of objects in memory. When you see this sort of pattern, you may want to investigate your application’s heap using heap dump analysis tools like yCrash, HeapHero, Eclipse MAT and figure out whether you need to cache these many objects in memory. Several times, you might uncover unnecessary objects to be cached in the memory. Here is the real-world GC log analysis report, which depicts this ‘Heavy caching’ pattern.
Great use cases, but an architectural nightmare that calls for a new role to plan and piece it all together into a coherent and viable system. This may be someone in a relatively new role, an IoT architect, or expanding the current roles of enterprise architects. The need for architects of either stripe was recently explored in a Gartner eBook, which looked at the ingredients needed to ensure success with enterprise IoT. ... Those having such capabilities in two or more of these areas will be in extremely high demand. The good news is that organizations can use existing digital business efforts to train up candidates." Responsibilities for the IoT architect role include the following: "Engaging and collaborating with stakeholders to establish an IoT vision and define clear business objectives."; "Designing an edge-to-enterprise IoT architecture."; "Establishing processes for constructing and operating IoT solutions."; and "Working with the organization's architecture and technical teams to deliver value." Then there's the enterprise architect -- who are likely to see their roles greatly expanded to encompass the extended architectures the IoT is bringing.
Quote for the day:
"Leadership is familiar, but not well understood." -- Gerald Weinberg